Typing in a directed identity URL is perfectly acceptable, and
required for some OP Google if there is no dedicated button.
Unless we change openID 2.0 (a possibility) we currently have two
existing services <Type>
One for normal logins and one for identifier select.
We need one rel each for that. They exiting <Type> URI may well work.
I don't know that delegating is the correct word for this.
It is not necessarily openID delegation.
It is an indirection to another XRD to get more information about the
desired relationship.
In XRI 2.0 this was called a redirect, but was not used by XRDS-Simple.
How openID uses LRDD and XRD to resolve endpoints is not something
that will be in the XRD spec itself.
It may be that we decide we don't need a special rel for the provider
relationship and that having the media type application/xrd+xml on the
two current rels is sufficient.
One other thing to think about is that we do have optional <Type>
elements for PAPE, AX, SREG and perhaps others.
Should those go in the users XRD as hints to RPs as additional rel
pointing to the providers XRD?
There are a bunch of things that we need to discuss about how XRD can
be used for openID discovery.
John B.
On 2009-09-04, at 1:27 PM, Santosh Rajan wrote:
If I understood you correctly, you are suggesting 2 endpoints and 1
delegate
Rel for Openid. The 2nd endpoint for identifier select.
Now this is what I am not clear about. Pls correct me If I am wrong.
1) Since the subject of this discussion is the users XRD, identifier
select
is not relevant here. The RP already has the users claimed_id. That
is what
he would have typed in (his OpenID) to get to his XRD. Unless of
cource he
typed his email like identifier, (which is webfinger).
2) If the user typed in his directed identity (a misnomer according to
some), that would be handled by his host-meta which would delegate
to his
XRDS like this.
<XRD>
<Host>example.com</Host>
<Link>
<Rel>http://openid.net/rel/delegate</Rel>
<URI>http://whatever.com/08/id</URI>
<MediaType>application/xrds+xml<MediaType>
</Link>
</XRD>
Please note above the mediatype is "xrds" not "xrd".
Also I think Nat's suggestion that we need a separate thread to
discuss
OpenID discovery WRT LRDD is what is required. I would go one step
more and
suggest we need a wiki page under "emerging tech".
If nobody wants to do that, I will do that if I find time this
weekend. :-)
John Bradley-7 wrote:
We still need two endpoints as well as the delegate to support
identifier select with openID 2.0.
John B.
On 2009-09-03, at 9:30 AM, 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
2) http://openid.net/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
-----
Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com
--
View this message in context:
http://www.nabble.com/XRD-and-OpenID-2.1-tp25252899p25298589.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
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
