Re: [xri] XRD trusted discovery workflow

[Breno de Medeiros <breno@google.com>]

On Tue, Dec 9, 2008 at 8:35 PM, Dirk Balfanz <balfanz@google.com> wrote:
> Thanks for putting that up, here are a few comments/questions:
> - Both in the PKI and in the out-of-band versions the basic verification
> step seems to go like this: you already have a canonical_id, and you do the
> following: (1) check that the canonical_id in the XRD document is the same
> as the canonical_id you're already holding, (2) verify the signature on the
> document, (3) verify that the key used to sign the document matches the
> canonical_id in the document. Why bother with the canonical_id in the
> document in the first place? Why not just (1) verify the signature, and (2)
> verify that the key used to sign the document matches the canonical_id
> you're already holding?

Unless the canonical id is used for delegation, it should be optional.
You could have the case where you arrive at the same document with
several canonical_ids. For instance, when you resolve a claimed_id
through /site-meta.

> - Do I understand this right that the <Delegation> element is for the case
> where the key that signs the next document in the discovery chain _doesn't_
> match the canonical_id? Things like
> <Type>http://specs.openid.net/auth/2.0/server</Type> (when present in a
> _signed_ XRD file)  still delegate, but the next document in the discovery
> chain would have to be signed with a key matching the canonical_id derived
> from the accompanying <URI> element. Right? If so, why have <Delegation>
> point to a key name? Shouldn't rather point to a canonical_id, so that we
> can use the basic verification step mentioned above (seems like otherwise
> the basic verification step doesn't apply to the case where I have both a
> canonical_id and a keyName going in to the verification step).

I agree with this. We already have a requirement that we need to be
able to go from canonical_id to keys, so using "delegate to
canonical_id" allows the client to use the same mechanism (which could
be <trust HTTP>, <trust HTTPS>, <trust simple-sign with SSL
certificates> or <trust simple-sign with specially distributed
certificates> to decide what to believe is the next key to sign the
document (if any).

Since it is clear that different clients will have different security
needs, we should have the concept of a trust profile, or a trust
handling mechanism, that tells what keys can be bound to
canonical_ids, and which is client-configurable. The documents should
then point to canonical_ids.

> - Having the URIMap element inside a Service element that also specifies a
> service type seems weird to me. It does have the advantage of being able to
> specify different resource maps for different service types, but somehow I
> always thought that there would be just one resource map (for XRD) for a
> site (perhaps from the days when I thought this would be in site-meta?). So
> I kinda expected something like <URIMap> as a direct child of the <XRD>
> element. I wonder what other people think about that.
> Dirk.
> On Tue, Dec 9, 2008 at 4:05 PM, Brian Eaton <beaton@google.com> wrote:
>>
>> On the Monday morning call I said I hoped to put out an "implementer's
>> draft" type of proposal.  I don't think we're quite there yet, but
>> I've put together lots of examples with specific syntax that I think
>> will be useful:
>>
>> http://wiki.oasis-open.org/xri/XrdOne/TrustWorkflowByExample
>>
>> In particular, this document describes the relation between site-meta
>> and XRD and where URI templates are specified.
>>
>> If this is confusing or just plain broken, let me know which bits and
>> I'll try to clarify.  Or maybe I'll be confused too, we'll see. =)
>>
>> ---------------------------------------------------------------------
>> 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:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)