[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XRD: Separating resource descriptions from authority
- Should we continue to support XRD/Service/Type (well, XRD/Link/Type)? There are useful use cases for providing discovery hints beyond media types, and we already have this widely deployed (more than any other feature) in XRDS. The first problem with this is the name, which will have to change since 'type' means media type in Link header and element. Is <Attribute> any better? <ResourceType>? This brings up a following questions: * if we change the element name at the Link level, should we also change it at the <XRD> level? * the XRD level <Type> has a new 'required' attribute which is used to warn applications not to interact with the resource if they do not understand a certain Type declaration. If we support a 'type' element at the Link level, should it also support this attribute? It can be very useful but the semantics are getting nuts here... A "required" attribute on a "hint" element... The CanonicalID seems to be used exclusively for trust, which makes me wonder if we shouldn't add a separate trust element that is about the XRD and not about the resource. One such idea looks like this: <XRD> <Expires>2009-01-01T08:30:00Z</Expires> <About>http://example.com/resource/1</About> <Type>http://example.com/type/profile_photo</Type> <Authority> <Identifier /> <Signature> <Base64 /> </Signature> </Authority> <Link> <URI>http://example.com/resource/2</URI> <Rel>http://example.com/rel/profile</Rel> </Link> </XRD> Where an authority element is introduced which identifies who is making the claims in the XRD and its certificate (or link) and the entire content of the XRD (without any Authority elements) in Base64 and its signature. This allows multiple signatures if an XRD is claimed to have multiple authorities. This way a document at google.com can describe a resource from example.com and include both signatures, or only one. And the consumer can look for a matching domain authority as the <About> resource(s) or for the URI that started the whole XRD discovery flow (which might not even be listed in an <About> element). For OpenID purposes, the existing use case of CanonicalID needs to be better defined and resolved. This is all very initial but something on my mind. EHL
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]