RE: [xri] trusted discovery workflow

[Eran Hammer-Lahav <eran@hueniverse.com>]

(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