XRD and OpenID 2.1

Thu Sep 3 20:35:59 UTC 2009

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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090903/86ed02b3/attachment-0001.htm>