Re: [xri] XRD: Separating resource descriptions from authority

[Nat Sakimura <n-sakimura@nri.co.jp>]

--------------------------------------------------
From: "Dirk Balfanz" <balfanz@google.com>
Sent: Tuesday, January 27, 2009 11:35 AM
To: "Eran Hammer-Lahav" <eran@hueniverse.com>
Cc: <xri@lists.oasis-open.org>
Subject: Re: [xri] XRD: Separating resource descriptions from authority

> On Mon, Jan 26, 2009 at 5:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> 
> wrote:
>> - 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>?
>
> I like ResourceType

I like ResourceType as well.

>
>>
>> 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?
>
> No, because at the link level it describes a relationship to _that_
> endpoint over there, e.g. "that is my OpenID provider over there". At
> the XRD level, it describes properties of the resource at hand, e.g.,
> "this OpenID provider supports PAPE". These feel different to me.
>
>> * 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...
>
> I'd vote for not putting it at the link level, but that's just a gut 
> feeling.
>
>> 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:
>
> To be honest, I'm not quite sure what the difference of <About> and
> <CanonicalID> is, but then I've only thought about this in the context
> of OpenID discovery. If you give us <About>, I don't think we need
> <CanonicalID>, at least not for OpenID discovery :-)

There can be many <About>. There can only be one <CanonicalID>.
<About> is similar to <LocalID> etc., I suppose.

<CanonicalID> is kind of important because you really do not know
which ID you want to associate with at the RP. The current OpenID spec
states that fragments etc. are added at the authentication service,
but I think that is a bug in the spec. It should be added at the
resolver, i.e., XRD, and that one is <CanonicalID>.

So, it could be such that

<XRD>
  <CanonicalID>https://example.com/peter#13243546</CanonicalID>
  <About>https://example.com/peter/</About>
  <About>https://peter.example.com/</About>
  <About>https://peter-davis.name/</About>
  <link>
     ...
   </link>
</XRD>

>
>>
>> <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>
>
> Yeah, something like that. I think Brian will send out a proposal soon
> (for the authority/signature section) that looks a lot like this,
> perhaps a little simpler.
>

But this would require canonicalization of the <XRD> which Brian had a
problem with. The current proposal on the wiki is

(1) Plain File with only one <XRD> or
(2) Sequence of <XRD />s with its plaintext content base64 encoded in
       an attribute of <XRD />

=nat