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
|