XRD and OpenID 2.1

John Bradley john.bradley at wingaa.com
Fri Sep 4 17:57:08 UTC 2009


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



More information about the specs mailing list