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


Nat,

 

I agree the element is valuable but instead of <ProviderID>, I would suggest using <CanonicalID> inside the <Service> element. In that placement, it represents the CanonicalID of the related resource.

 

It would simplify things and bring it in line with what CanonicalID means as a child of the <XRD> element.

 

=Drummond

 


From: Nat Sakimura [mailto:n-sakimura@nri.co.jp]
Sent: Tuesday, December 09, 2008 11:57 PM
To: 'XRI TC'
Subject: [xri] Service/ProviderID

 

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



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