[OpenID] Open Challenge to webfinger and XRD

[Drummond Reed]

>
>> If you have ideas on the proper W3C friendly way to name the subject of
>> the meta-data for all the protocols relating to a DNS name,  I am quite
>> interested in your opinion.
>>
>
> There is a large amount of data out there regarding different ways of
> naming things, both with URIs and without. I don't think that my opinion is
> any more helpful than anyone else's on this subject, but I would say this
> about XRD, and how it appears to disallow certain extensions in this area
> that might be helpful:
>
> i) The Subject element seems to be of xsd:type anyURI, which disallows
> someone from creating their own "registry" of (string) names, for example,
> and/or defining subjects as simple string values (as proposed below by Dirk
> I think). It would be possible within the rules of XSD/RelaxNG to define a
> more open content model - start with a string, and then define a restriction
> to anyURI for that kind of XRD usage, but allow extensions by others to
> either restrict the open type more, or use it as-is.
>

John, thanks, that's very insightful. I think the scope of XRD is intended
to be as a descriptor for any resource with a URI, which is why the XRI TC
choose the anyURI type. But if there's a strong case for making it even
wider, that could be considered. That's what the public review period can
help determine (which should begin ~ Nov 1 - we're just finishing the
Committee Draft vote right now).


> ii) There seems no extension currently possible on the Subject element that
> would allow the creator of the XRD to indicate the "type" of the Subject and
> thus make the relationship known that way.
>

That does not require an extension to the Subject element -- it's handled by
its sibling element called <Type>. An XRD may have 0 or more <Type> elements
(which take URIs as values) to define the type.

>
> FWIW, SAML 2.0 does a nice job of allowing extensions such as the above.
>
> I find it odd that an XRD could really have no Subject, but again, I don't
> know the use-case for that, or whether this is simply done to allow someone
> to create Subjects which aren't named with URIs (in which case, I would
> suggest allowing XSD extensions might be a better path).


I believe the use case for Subject being an optional element was that in
some cases the Subject will be implicit and therefore not needed.

Best,

=Drummond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091020/9a9f6dd3/attachment.htm>