Re: [xri] trusted discovery workflow

[Ben Laurie <benl@google.com>]

On Fri, Dec 5, 2008 at 7:09 AM, Drummond Reed
<drummond.reed@cordance.net> wrote:
>> >> On Thu, Dec 4, 2008 at 12:06 PM, Drummond Reed
>> >> <drummond.reed@cordance.net> wrote:
>> >
>> >> From a first read-through, it looks like XRI 2.0 trusted resolution
>> >> using
>> >> SAML signatures as defined in section 10.2 of [1] conforms to your
>> >> algorithm. (I'm not at all suggesting we use that for XRD since it was
>> >> complex enough that there was only one early implementation.) I'm just
>> >> testing my understanding of the algorithm you are proposing for "signed
>> >> links".
>> >>
>> >
>> > Brian Eaton wrote:
>> >
>> > They definitely have some similarities.  In particular the sentence...
>> >
>> > "If the digital signature enveloped by the SAML assertion contains a
>> > ds:KeyInfo element, the resolver MAY reject the signature if this key
>> > does not match the signer's expected key as specified by the
>> > ds:KeyInfo element present in the XRD Descriptor that was used to
>> > describe the current authority."
>> >
>> > ... makes me think that there is a similar concept of delegation
>> happening.
>> >
>> > I'm not 100% sure of that, though.
>> >
>>
>> Nat Sakimura wrote:
>>
>> Before I start tackling this, let me be sure of what it is trying to
>> achieve.
>> Since it is XRD/XRI discussion list, I will think in terms of XRD.
>>
>> The authenticity of individual XRD can be estabilished by just
>> inspecting it through SimpleSign.
>> (See SimpleSign proposal how it is so.)
>>
>> The XRD document points to another resource with its own XRD for a
>> service.
>> This may be pointing to yet another resource with its own XRD, etc., so
>> it creates a chain.
>> What this TrustWrokflow is trying to achieve is to evaluate the
>> authenticity of this chain.
>> (This actually is what XRI Trusted Resolution 2.0 tried to solve.)
>>
>> Is this correct?
>>
>> If so, I have another question. (This applies to XRI Trusted Resolution
>> 2.0 as well.)
>>
>> In my view,
>>
>>    R0 deligating to R1
>>    R1 deligating to R2
>>
>> does not necesarily mean that R0 agreed to deligate to R2.
>> i.e., the transitivity is not granted unless it is explicitly done so.
>>
>> How is such cases being handled?
>>
>> #I feel that there should be a flag that indicate further deligation is
>> allowed in the original XRD/Service element.
>>
>> =nat
>
>
> Nat, is it necessary that R0 give R1 the right to delegate? Isn't is simpler
> to assume that if R0 delegates to R1, that's as far as the trust chain goes
> (i.e., that link is trusted), but you must then check if R1 really delegates
> to R2?
>
> In other words, isn't it enough to trust each link in the chain? Otherwise
> tracking delegation permissions from R0 to Rn would become exponentially
> complex.

I agree - once you've delegated to R1, you should not try to exercise
further control over how it provides the service. Note that if you
forbid further delegation it could always provide the same effect
(less efficiently) by proxying, so it doesn't seem like there's much
point in trying to prevent it, in any case.