[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]