[OpenID] host-meta and "acct:"

[Will Norris]

On Nov 1, 2009, at 8:13 AM, Peter Williams wrote:

> Yes. Only the XRD element has an xml:id attribute, schematically.  
> But I
> could not detect your point, of saying this fact.

I imagine he was responding to your statement that:

> The subject has to bear the xml:id

XRD's extensibility model certainly allows you to put an xml:id on the  
<Subject> if you want to, though that would certainly not be the  
xml:id used as the <ds:Reference> in the signature.  The Signature, if  
present, MUST reference the xml:id attribute of the root XRD element  
being signed.  Keep in mind that this may or may not be the root  
element of the XML document, as in the case of XRDS.


> And, a subject name is about an XRD in a context (in general). One  
> such
> context is the native signing/trust model (if used).

I'm not completely sure what you mean here.  The subject identifies  
the resource the XRD is about, regardless of "context" (maybe  
depending on how you define context?).

To maybe clear up some of the discussion around Subject, and whether  
or not it is required (and hopefully not to re-open a can of worms  
that has seemed to die down)...  (and I realize I just sent some of  
this in another thread on this list, but it's worth repeating)


An XRD Subject is effectively useful for two things.

   1. It identifies the resource the XRD is about

   2. It is anticipated that some XRD trust profiles will use the  
subject URI to varying degrees to assess the trustworthiness of a  
signed XRD.  One example is by comparing the subject URI to key  
material used to generate the signature.  None of these XRD trust  
profiles have been written yet, so no one can say with any certainty  
exactly what they will contain.  I CAN tell you that we have discussed  
profiles that will most certainly make use of Subject, and we have  
also discussed profiles that will very likely NOT make use of Subject.


Subject is not a required element of XRD.  What it actually means for  
an XRD to lack a Subject depends on a few things...

   2. If the XRD is signed, then clearly it must be using a trust  
profile that does not require a Subject.  Remember, no XRD trust  
profiles exist yet, but we do anticipate that there will be one or  
more that won't require a Subject.  That can't be said with any  
certainty because we just don't know yet.

   1. How do you know what resource an XRD is about if you don't have  
a subject?  As far as XRD proper is concerned, the answer is  
undefined.  XRD 1.0 gives you one way to identify the resource the XRD  
is about, but says nothing about what it means if the Subject is  
absent.  This is intentional... we didn't want to preclude other ways  
of identifying the subject (or maybe even subjects, plural) of the  
XRD.  What implication will these other subject-identifcation methods  
have on applications and protocols that use XRD for resource  
description?  We can't really answer that, because we don't know.  For  
the use-cases we've been able to identify so far, and the ones we've  
had in mind while designing XRD, it seems to work out okay.

It is entirely possible that some applications will require the  
presence of an XRD Subject element, and that's perfectly okay.  XRD  
can be profiled to add whatever additional constraints a particular  
application or protocol needs to be useful, secure, scalable, etc.

So what about XRDs that don't contain a Subject element, nor contain  
any other defined way of identifying the resource(s) the XRD is  
about?  Again, this is undefined.  If you're unable to identify (by  
whatever means) the subject (explicit or implied) of the XRD, I can't  
tell you what that means.  It doesn't sound terribly useful.  Would it  
be a valid XRD?  Yes, absolutely.  Is it a useful XRD?  No, probably  
not, though someone may come up with a valid case for it.  By the same  
token, the following is also a completely valid XRD document:

<XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0" />

It's not useful at all, but it's entirely valid.


Try not to get too hung up on Subject.  In many common use cases,  
Subject will be present, and you won't have to worry about it.  In  
cases where Subject is not present, then there will need to be some  
other defined means for providing the necessary information to address  
common uses that Subject is used for.  As long as you have some other  
means to identify the resource the XRD is about and, if necessary, a  
way to assess the trustworthiness of a signed XRD, then you can get by  
just fine without a formal Subject element.

-will