David Fuelling wrote: > I'm wondering if the following is a correct interpretation of how OpenId 2.0 > uses Yadis. Any clarifications are appreciated. > > 1.) User navigates to an RP, and enters a Claimed Identifier (e.g., > http://sappenin.gmail.com). > > 2.) A Yadis doc is returned as follows: > > <Service xmlns="xri://$xrd*($v*2.0)"> > <Type>http://specs.openid.net/auth/2.0/server</Type> > <URI>https://sappenin.com/</URI> </Service> > </Service> > > > Specifically: > > A.) Is this the proper way to do delegation? Above, gmail.com is delegating > to sappenin.com.
What you've given above isn't delegation, because no delegate identifier is given. I guess you wanted https://sappenin.com/ to be your identifier, in which case it would go in the <LocalID> element, with your provider's endpoint URL in <URI>. Also, the Type here should be http://specs.openid.net/auth/2.0/signon. You can also do it with LINK elements in an HTML document, as with OpenID 1 (though the "rel" values have changed a little). > B.) If a client gets the Yadis doc above (after navigating to gmail.com), > MUST they (or SHOULD they) navigate to sappenin.com and try to perform > discovery again? If so, how many delegates are allowed? Not specified? > Delegation isn't recursive. When given the above (corrected, of course), the site will try to verify https://sappenin.com/ against the given server immediately. Discovery is never performed on the LocalID in this case. This means that the nominated provider *must* be able to recognise the LocalID given. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs