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


That actually is a good point.
 
While it is nice being succinct, sometimes verboseness helps for people to understand.
 
I feel that the word "ProviderID" is actually pretty good because it is the ID of the service provider.
 
=nat
 

差出人: John Bradley [jbradley@mac.com]
送信日時: 2008年12月11日 0:33
宛先: Sakimura Nat
CC: Drummond Reed; 'XRI TC'
件名: Re: [xri] Service/ProviderID

I would be concerned about causing confusion between the User's CID and the Services CID.

I see Drummond's point but an concerned that it could lead to confusion by users if the XRD has multiple things called CID.

If ProviderID is not clear then I would prefer something like TargetCID or RelatedCID

=jbradley
On 10-Dec-08, at 6:48 AM, Nat Sakimura wrote:

I am fine with CanonicalID.

I suggested ProviderID merely because it was already there...

=nat

Drummond Reed wrote:

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


--
Nat Sakimura (=nat)
Nomura Research Institute, Ltd. XDI.ORG Vice Chair


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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