OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] Service/ProviderID


Thanks for the slide.

The one part I don't quite get is why in the openID SEP don't you do  
discovery on https://nri.co.jp/# !1616!0001 rather than http://uniid.nri.co.jp/server/

They must be synonyms, and require the same number of steps to resolve.

If you resolve http://uniid.nri.co.jp/server/  and it produced some  
other CID would you fall back and resolve the CID or error?

Now I could see the URI element being diffrent if it were the actual  
openID endpoint but published link headers to http://uniid.nri.co.jp/server/xrd 
  rather than doing a 303.

That could have a useful backwards compatibility of sorts.  Perhaps  
that is what you are thinking as the same URI is repeated in the  
openID SEP in the delegated XRD.

I would personally like to see the SEP contain only the ProviderID and  
perhaps LocalID or other-elements that might override or extend the  
elements in the delegated XRD.  Overriding is perhaps a debatable idea  
but at-least extend.

=jbradley



On 10-Dec-08, at 8:21 PM, Sakimura Nat wrote:

> Hi John,
>
> I have created a slide depicting the relationships between URI/CID/ 
> LinkHeader/XRD/X509.
>
> Perhaps this will help.
>
> =nat
>
> 差出人: John Bradley [jbradley@mac.com]
> 送信日時: 2008年12月11日 0:24
> 宛先: Sakimura Nat
> CC: 'XRI TC'
> 件名: Re: [xri] Service/ProviderID
>
> Nat if you have the CID of the service provider you could just use  
> that to retrieve the XRD.
>
> This assumes of corse that we enforce that the XRD associated with a  
> CID is always retrievable from the CID via XRD discovery.
>
> Are you thinking that the URI element be used as a resolution  
> shortcut to the resource URI of the XRD to avoid going through  
> sitemeta etc to retrieve it?
> Or is the URI element only intended for backwards compatibility?
>
> Though if we are changing from <Service> to <Rel> we have already  
> broken the backwards compatibility with Yadis.
>
> =jbradley
>
>
> On 10-Dec-08, at 4:56 AM, Nat Sakimura wrote:
>
>> In the F2F at the iiw2008b (iiw#7), we have more or less agreed to  
>> deprecate <ProviderID>.
>> I started to feel that while deprecating XRD/ProviderID, preserving  
>> XRD/Service/ProviderID may be worthwhile.
>>
>> The reason is as follows:
>>
>> There are two types of XRDs.
>>
>> 1) XRD that describes its own service.
>> 2) XRD that describes the service that it relates to / it uses.
>>
>> In the former, there is not point in having <ProviderID> as it is  
>> identical to <CanonicalID>.
>>
>> In the later case, however, it would be nice to have it so that it  
>> would appear like:
>>
>>   <Service>
>>     <ProviderID>https://example.com/server#14235435672</ProviderID>
>>     <Type>http://specs.openid.net/auth/2.0/signon</Type>
>>     <URI>https://example.com/server</URI>
>>   </Service>
>>
>> XRD/Service/ProviderID points to the <CanonicalID> of the service  
>> provider, in this case, OpenID Authentication Provider.
>>
>> Relying party retrieves this user's XRD and finds the  
>> ProviderID=CanonicalID of the OpenID Authentication Provider. Then,  
>> the RP retrieves this Authentication Provider's XRD to find out the  
>> actual endpoint. It would look like (I am ommiting signature  
>> element):
>>
>> <XRD>
>>   <CanonicalID>https://example.com/server#14235435672</CanonicalID>
>>   <Service>
>>     <Type>http://specs.openid.net/auth/2.0/signon</Type>
>>     <URI>https://example.com/server/signon</URI>
>>   </Service>
>> </XRD>
>>
>> When it does, it checks the CanonicalID to see this is the XRD of  
>> the intended Service and then checks the  signature with the cert  
>> that has this CanonicalID as the SubjectUniqueIdentifier. This way,  
>> the RP finds out that this Authentication Provider IS the one that  
>> was delegated by the user.
>>
>> =nat
>
> <XRD-x509-relation.ppt>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]