RE: Delegation (was: trusted discovery workflow)

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

What would be the real world use case for limited delegation powers?

The way I see it, we have two mechanisms that in practice translate to 'delegation':

The <XRD:Ref> element voids anything else within the XRD and basically points to another entity to provide the full resource descriptor. An open question for me is what is <Ref> pointing to? Another resource or another XRD?

The <XRD:Service> element is in many cases (such as OpenID) a service-specific delegation of some control.

EHL

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Thursday, December 04, 2008 11:10 PM
> To: 'Nat Sakimura'; 'Brian Eaton'
> Cc: xri@lists.oasis-open.org
> Subject: RE: [xri] trusted discovery workflow
>
> > >> 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.
>
> =Drummond
>
>
> ---------------------------------------------------------------------
> 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