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

xri message