OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xri] Subject and authority

On Fri, Aug 21, 2009 at 11:49 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
I think the reason why we are having such a hard time with dealing with Subject is that we have overloaded this element with too many purposes.

At this point Subject means:

* The context URI of the XRD
* The canonical identifier of the resource the descriptor is associated with
* The source of authority information for establishing trust

Host-meta does not need the first two because they are not defined by the document found at the well-known location but by the protocol. What this means is that if you find a host-meta that does not describe exactly what you expect, the protocol fails. It doesn't allow for other scoped. You also don't stumble upon host-meta files. They must be obtained in a certain way.

What host-meta needs is a trust framework which allows clients to assert that the author and signer of the document intended it to be used as a host-meta file for that specific host, and that it has the authority to do so.

This is not yet a proposal, just something to get a discussion going. This morning I wrote why DeWitt's proposal of expressing Subject and Alias as links is not a good idea. But the only reason not to do so is our dependency on Subject for trust requirements. Expressing Subject as a link makes the document harder to validate because it means having to go dig for an authority.

But what if instead of a Subject and Alias we used links (maybe 'canonical' and 'self'), and we add a new element <Authority> which is a string, and is used by trust profiles. Then each trust profile can make up their own rules about its content, its relation to the canonical URI, and its matching to the certificate used to sign the document.

I think this <Authority> field is exactly the same as the name in the signing certificate. Any trust profile that puts constraints on the relationships between <Authority> and <Subject> can, today, put exactly those constraints on the relationship between the signing cert and <Subject>. So I'm not sure this would help. For example, I don't see how this gets rid of the need to have non-URI Subjects. 


  <Signature>...something signed by evil.com...</Signature>

Presumably, the OpenID trust profile would have to be written in a way that this XRD would not pass verification (absent of some sort of delegation statement from example.com to evil.com). So, it would probably say something like 

- check that the Authority equals the Subject
- check that both equal the identity you're performing discovery on
- check that the document is signed by the authority

So we'd back to having Subject be something that can be a URI, or a host.

I'm still in favor of the <Host> idea for host-meta, as an alternative way to describe the subjects of host-metas.




To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]