[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] trusted discovery workflow
(see my previous message) We need to be careful what we define as delegation. Both <Ref> and <Service> provide a way to delegate something to another entity. But they delegate different things. One is a delegation of the descriptor itself and the other is of a specific service in a specific context. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, December 05, 2008 7:41 AM > To: Ben Laurie > Cc: Drummond Reed; Nat Sakimura; xri@lists.oasis-open.org > 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. > > > > --------------------------------------------------------------------- > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]