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
