Yes, http://openid.net/rel/my_op looks better.
Nat Sakimura-2 wrote: > > 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 <[email protected] >> <mailto:[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 >> <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 >>> <[email protected] <mailto:[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] >>> <mailto:[email protected]> >>> >>> http://lists.openid.net/mailman/listinfo/openid-specs >>> >>> >>> _______________________________________________ >>> specs mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openid.net/mailman/listinfo/openid-specs >>> >>> _______________________________________________ >>> specs mailing list >>> [email protected] <mailto:[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 >> > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > > ----- Santosh Rajan http://santrajan.blogspot.com http://santrajan.blogspot.com -- View this message in context: http://www.nabble.com/XRD-and-OpenID-2.1-tp25252899p25298082.html Sent from the OpenID - Specs mailing list archive at Nabble.com. _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
