Re: [xri] trusted discovery workflow

[Brian Eaton <beaton@google.com>]

There are some real use cases for N levels of delegation.  For
example, my hosting provider might delegate to an IdP that might
delegate portable contacts to somewhere else...

On Fri, Dec 5, 2008 at 5:00 AM, Ben Laurie <benl@google.com> wrote:
> 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.
>