[OpenID] Summarizing my grouse with XRD

John Bradley ve7jtb at ve7jtb.com
Thu Oct 22 03:16:56 UTC 2009


I suppose if we were starting fresh we could have called it RDML.

I don't know that there is a meaningful distinction between a document  
format like  OpenDocument and meta-markup language like SAML.    
Technically they are the same.

The XRI-TC will also be producing a XRI 3.0 spec that will use this  
updated XRD document specification.

Webfinger and others may also produce processing specifications for  
XRD or profiles of XRD.

XRD is NOT an identifier.

XRDS as currently used in openID discovery stands for eXtesable  
Resource Descriptor  Sequence.

Yadis never made any use of the Sequence feature so we made it optional.

Hense the main document format spec is now called XRD and not XRDS.

I know people are planning on using it with a multitude of different  
identifiers including email addresses.

It is still XML and the document is a meta-data descriptor not an  
identifier.

John B.

On 2009-10-21, at 11:13 PM, Santosh Rajan wrote:

> In other words now you are saying that XRD is another markup  
> language like HTML and SAML. In which case you should be calling it  
> "XRML" for Extensible Resource Markup Language.
>
> So what started as a "Descriptor" has morphed into a "Markup  
> Language".
>
> So this gives scope for someone else to write the "REAL" Extensible  
> Resource Descriptor Specification on top of XRML.
>
>
> On Thu, Oct 22, 2009 at 2:24 AM, John Bradley <ve7jtb at ve7jtb.com>  
> wrote:
> XRD is a XML document spec.
>
>
> On 2009-10-21, at 5:21 PM, John Kemp wrote:
>
> John Bradley wrote:
> It means that some protocol that is using XRD is defining the  
> subject via some external mechanism.
>
> So the XRD spec. is a template spec. meant to be simply incorporated  
> by reference into other specs. I guess?
>
> Like other XML specs eg SAML 2.0 it can be used multiple  
> specifications that process XML documents.
>
> External specs can profile the XRD spec.
>
>
> In the HTTP protocol case there may be an implicit subject based on  
> the identifier that is being resolved.
>
> As mentioned earlier, if the _subject_ of the XRD is identified  
> (implicitly) by the same URI used to retrieve the XRD itself, then  
> that seems rather circular.
>
> The XML document describes a resource and provides links to  
> associated resources.
> A HTML page doesn't need to explicitly say what URI it is retrieved  
> from in its internal markup.
>
> Like with HTML sometimes the subject is defined by the transport or  
> other external method.
>
> Thanks
> John B.
>
> All normal http caching would apply in the http: case.
>
> Sure, I'm not quibbling with caching...
>
> In the IMI/SAML case we have discussed pushing a XRD as a assertion/ 
> claim.
> In that case the subject may be the same as the saml:NameID in the  
> containing saml:Assertion.
> It could perhaps be argued that putting a xrd:Subject and signature  
> inside a signed saml:Asertion is un-neccicary.
> Suffice to say it is up to the protocol using XRD to decide what to  
> make of a XRD without a xrd:Subject.
>
> OK, I think I've understood ;)
>
> Cheers,
>
> - johnk
>
> John B.
> On 2009-10-21, at 3:09 PM, John Kemp wrote:
> John Bradley wrote:
> Yes a XRD can be used for identity.  In that case it should be a  
> signed XRD (with Subject)
> However a XRD can be used to describe any resource (URI).
>
> What does it mean then (in XRD terms) if an XRD doesn't identify the  
> resource it describes (ie. it doesn't have a subject)?
>
> - johnk
>
>
>
>
>
> -- 
> http://hi.im/santosh
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091022/ec253ced/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2468 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091022/ec253ced/attachment.bin>


More information about the general mailing list