XRD and OpenID 2.1

Nat Sakimura n-sakimura at nri.co.jp
Fri Sep 4 04:48:44 UTC 2009


You do not want to state the endpoint. You only want to sate the 
provider, IMHO.
So, http://openid.net/rel/endpoint would not be a good naming.
I like something in the line of

http://openid.net/rel/op etc. or more verbose version of it like:
http://openid.net/rel/my_op etc.

=nat

Santosh Rajan wrote:
> To make discovery easier  for an RP, I suggest we limit the RP to look 
> for one of two resources in a users XRD.
> 1) An OpenID Endpoint
> 2) An OpenID Delegate.
> If an OpenID endpoint is not available in a users XRD, the RP will 
> next look for a delegated host. In both cases the RP is looking for a 
> Rel value in a Link Element. So I suggest something like this for Rel 
> values
> 1) http://openid.net/rel/endpoint <http://openid.net/op/endpoint>
> 2) http://openid.net <http://openid.net/op/endpoint>/rel/delegate
>
> On Thu, Sep 3, 2009 at 10:55 AM, Nat Sakimura <n-sakimura at nri.co.jp 
> <mailto:n-sakimura at nri.co.jp>> wrote:
>
>     The first XRD in my example is the "User Discovery" XRD in Dirk's
>     post.
>     I am talking about what to use for <rel> URI here.
>     In XRI TC's discussion, we disccussed that it probably is not
>     right to
>     use the same URI for both "User Discovery" document (which defines
>     relationship, "Relationship URI") and "Provider Discovery" (which
>     defines the service).
>     I suppose Dirk is using the same URI just for the lack of this
>     "Relationship URI".
>
>     Also, in Dirk's example, in User Discovery, he is siting
>     <URI>http://openid.example.com/op</URI>
>
>     I suppose this is somewhat misleading.
>     I suppose it should be
>
>     <URI>http://example.com/#<URI>
>
>     (Note: I have added # to denote that it is pointing to a non
>     information resource.
>     As it is a non-information resource, the matching information
>     resource has to be
>     discovered by some other protocol, such as LRDD/site-meta.)
>
>     As to the Provider Discovery is concerned, there is no <Host> in
>     the latest XRD schema.
>     It is unified with <Subject>. How to express the "Subject Set" or
>     entire domain is
>     still under discussion, I believe, in site-meta discussion. The
>     last I have seen is
>     something like: <Subject>site-meta://example.com
>     <http://example.com></Subject>.
>     Personally, I do not like it. (W3C people will not either, I think.)
>     What some XRI TC people suggested was to use something like
>     <Subject>http://example.com/#</Subject> as in AWWW, but this is
>     something
>     that should be discussed in another thread.
>
>     What I was referring to as "not sure" was whether we need to
>     support all types of LRDD
>     or just one, for OpenID. I have got an opinion on that but I am
>     intending to start
>     yet another thread for that. (Or somebody else can do so. I am
>     rather time constrained.)
>
>     I think it is a good practice to separate those threads and
>     concentrate on one issue
>     per thread so that we can avoid drifting discussion.
>
>     This thread is only about the Relationship URI.
>
>     =nat
>
>
>
>     Santosh Rajan wrote:
>>     There is an article posted here related to this.
>>     http://www.hueniverse.com/hueniverse/2009/09/openid-and-lrdd.html
>>
>>     So how does this work in the above framework?
>>
>>
>>     On Thu, Sep 3, 2009 at 9:26 AM, Nat Sakimura
>>     <n-sakimura at nri.co.jp <mailto:n-sakimura at nri.co.jp>> wrote:
>>
>>         So, User's XRD would have something like
>>
>>         <xrd id="foo">
>>         <Subject>http://sakimura.org/nat</Subject>
>>         <ds:Signature> ... </ds:Signature>
>>         <link>
>>         <rel>http://openid.net/rels/myopenid_provider</rel>
>>         <url>http://myopenid.net/</url>
>>         </link>
>>         </xrd>
>>
>>         This is fetched during the discovery. (I am still not so sure
>>         about
>>         the relationship between X-XRDS-Location: header and
>>         site_meta etc.
>>         Are we abandoning the header model?)
>>
>>         Then, the RP searches for my relationship with OP through <rel>.
>>         Once it was found, the RP goes to the url specified in the
>>         <link> to
>>         get the Service's XRD like:
>>
>>         <xrd id="baa">
>>         <Subject>http://myopenid.net/</Subject>
>>         <ds:Signature>...</ds:Signature>
>>         <link>
>>         <rel>http://openid.net/op/endpoint</rel>
>>         <url>http://specs.openid.net/auth/2.0</url>
>>         </link>
>>         </xrd>
>>
>>         to find out the concrete endpoint of this authentication service.
>>
>>         =nat
>>
>>
>>         John Bradley wrote:
>>
>>             Allen,
>>
>>             In XRD 1.0 we are moving to a link based model.
>>
>>             So a users XRD rather than having to specify the openID
>>             providers service can point to an openID provider.
>>
>>             The URIs that we currently use describe the service not
>>             the provider.
>>
>>             I think Nat is looking for a link relationship that
>>             describes a user pointing  to a service providers XRD
>>             rather than to the service itself.
>>
>>             There will be a bunch of new link types required for
>>             various protocols.
>>
>>             John B.
>>
>>
>>             On 2009-09-02, at 5:27 PM, Allen Tom wrote:
>>
>>                 Hi Nat,
>>
>>                 Can you explain the problem in a bit more detail? Can
>>                 you give an example use case?
>>
>>                 Thanks
>>                 Allen
>>
>>
>>                 Nat Sakimura wrote:
>>
>>                     The second topic for OpenID 2.1
>>
>>                     Maybe, it should be separated to the Discovery but...
>>
>>                     In XRD 1.0, we need to define <Rel> type url for
>>                     the user=OP relationship.
>>                     What shall we use?
>>
>>                     Something like:
>>
>>                     http://specs.openid.net/rel/openid_provider#
>>
>>                     =nat
>>                     _______________________________________________
>>                     specs mailing list
>>                     specs at lists.openid.net
>>                     <mailto:specs at lists.openid.net>
>>                     http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>>                 _______________________________________________
>>                 specs mailing list
>>                 specs at lists.openid.net <mailto:specs at lists.openid.net>
>>                 http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>         _______________________________________________
>>         specs mailing list
>>         specs at lists.openid.net <mailto:specs at lists.openid.net>
>>         http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>>
>>
>>     -- 
>>     http://santrajan.blogspot.com
>>     http://twitter.com/santoshrajan
>>     http://www.facebook.com/santosh.rajan
>>
>>
>
>
>
> -- 
> http://santrajan.blogspot.com
> http://twitter.com/santoshrajan
> http://www.facebook.com/santosh.rajan
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090904/e0131956/attachment.htm>


More information about the specs mailing list