[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] trusted discovery workflow
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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]