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> <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 <[email protected]> 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</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 <[email protected]> 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 >>>>> [email protected] >>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>> >>>> >>>> _______________________________________________ >>>> specs mailing list >>>> [email protected] >>>> http://lists.openid.net/mailman/listinfo/openid-specs >>> >>> _______________________________________________ >> specs mailing list >> [email protected] >> 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 [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
