[OpenID] user centric delegation vs portability: LRDD : competing threats: the consumer's fear hypothesis

[John Bradley]

I don't think openID will look in the host-meta for the OP.

I suppose that it could but that would defiantly not be user centric  
behaviour.

Users don't enter a host-meta identifier.   It is used as one of the  
ways to discover the XRD for an identifier.

It is not a XRD for the identifier itself.

In the case of example.com if I want to find the XRD for https://example.com 
  (say it is used as a OP identifier for directed identity) and example.com 
  doesn't want to use link headers for some reason.

The resolver first retrieves host-mata from the well known location.

It retrieves it via https or verifies the signature of the XRD.

(Yes Santosh if the XRD had dns:example.com as the subject that would  
work to verify it)

The resolver then determines if the XRD's scope includes https.

If it is in scope the resolver uses the matching template for the  
scheme + host + port with https://example.com as the input and  
produces the new URI where the XRD for https://example.com can be  
retrieved from.

It could be http://bar.com/xrd/example.com or anything else for that  
matter.

It is the Links in that XRD that control who the OP is.

There are lurking questions about if a XRD retrieved over http can be  
authoritative for schemes other than the one it was retrieved via.

My contention is that the subject (it may not be called that) of the  
XRD is the subject of the SSL certificate that is signing it.

The XRD should be self standing.  This is important if you want it to  
be able to map identifiers that don't have there own transport  
protocol that can return a document.   I would class email addresses  
as that.  Yes you could modify SMTP but you don't want to.

I prefer to think of host-meta as being part of the X.509 trust chain  
that can delegate trust to down stream XRD rather than something that  
is rooted directly in the URI authority hierarchy.

The discussion is ongoing.  My opinion may well not be the majority  
one at the end of the day.

John B.

On 2009-10-27, at 9:49 PM, Manger, James H wrote:

> John,
>
> > Host-meta doesn't provide the OP.
> > It provides a mapping from some identifier to a XRD for that  
> identifier.
> > It is the target XRD for the user that specifies the OP.
>
> Thanks for reminding me of the extra layer of indirection.
> That does mean a solution where host-meta takes precedence still has  
> some flexibility to handle, say, a different OP for just a few  
> special OpenID URIs on a site.
>
>
> Host-meta now uses the XRD syntax. It no longer just looks like a  
> mapping from identifiers to the metadata (XRD) for each identifier.  
> It now looks like common metadata (XRD) for a host of identifiers,  
> optionally with a reference to more identifier-specific metadata  
> (XRD).
>
> If host-meta can say: the ‘describedby’ link for all URIs at this  
> host is xyz; why shouldn’t it say the ‘openid2.provider’ link for  
> all URIs at this host is abc? The semantics seem to work, as long as  
> RPs are looking for this relation in host-meta.
>
> A ‘describedby’ link in an XRD looks like an app-layer version of an  
> HTTP redirect: you can have 0, 1, or more of them. [Perhaps an  
> “@import url(…)” statement in a cascading stylesheet is a better  
> analogy, as it also has issues of merging data from various sources.]
> I guess a higher layer, like OpenID, might choose to mandate that  
> “there MUST be exactly 1 level of indirection” (ie host-meta SHALL  
> specify a ‘describedby’ link, but no ‘openid*’ links; whereas an  
> OpenID identifier’s XRD SHALL NOT include a ‘describedby’ link).
>
> James Manger
> James.H.Manger at team.telstra.com
> Identity and security team — Chief Technology Office — Telstra
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091028/697ecb3f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2468 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091028/697ecb3f/attachment-0001.bin>