[OpenID] host-meta and "acct:"

Fri Nov 6 05:31:20 UTC 2009

i was simply comparing the way signed XRD happend in XRI v2 with what the
elements/atributes that are (not) present in the "comparable" element of the
XRD 1.0 (subject).

if one reads the openxri code for validating an signed XRD (which aligns
with the standard even!), one must ensure that the attribute value for
xml:id in the comparable "subject"  field is that of the XRD element which
encloses that field. Similarly, there MUST be a providerID (that denotes the
superior XRD in the XRDS whose keying material MUST be used to verify the
signature.

What we are learning is there is a value-extensibility model - for signed
XRD 1.0 - that via a profile will probably just put back the providerID and
xml:id reference - so the validity logic of XRI 3.0's HXRI's still works the
very same way it did in XRI 2.0 (for XRIs and HXRIs alike).

Alternatively, the profile may impose a validation logic that has noting to
do with structured names -  that is not based on providerids formally
"chaining" a set of a contextual XRDs in an XRDS. 

Im those alternative profiles that are not about resolution of structured
names, there seems no reason to enforce the rule that only the "superior"
arc in some graph interpretation of the XRD values can bear the signature's
keying material. perhaps the public key is allowed to come from a
authenticated foaf file, even... that then provides a context for evaluating
signed XRD values.

Im happy now I udnerstand the direction. Its evidently the same in spirit as
XRI 2.0, but actually clearer in that profiles can entirely avoid
structured-name centric validation logics.

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

-- 
View this message in context: http://old.nabble.com/host-meta-and-%22acct%3A%22-tp26079872p26226561.html
Sent from the OpenID - General mailing list archive at Nabble.com.