RE: [xri] trusted discovery workflow

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

This is easier to do with <Ref> but not so easy with <Service>. What makes even <Ref> tricky is support for redundancy (i.e. 'priority') where an attribute will only apply to a single <Ref>, creating a configuration complexity.

The textbook case is well understood, but I would still like some use cases applicable to current work.

EHL

> -----Original Message-----
> From: Sakimura Nat [mailto:n-sakimura@nri.co.jp]
> Sent: Friday, December 05, 2008 11:02 PM
> To: Drummond Reed; 'Brian Eaton'
> Cc: xri@lists.oasis-open.org
> Subject: RE: [xri] trusted discovery workflow
>
> The discussion seems to have come to some kind of conclusion by now so
> I guess it is a bit redundant, but I would like to point two things.
>
> 1) It is pretty common in the real life contract to prohibit further
> deligation. I thought it might be worthwhile to capture this aspect.
> The trust being not transitive is a classic textbook case, too.
> 2) Checking if further deligation is allowed does not get exponential.
> It just amounts to be checking two most recent arcs. If the origin does
> not allow re-deligation, and the destination re-deligates, the link
> breaks there and processing stops. If the origin allowes re-deligation,
> then it goes on. It is that simple.
>
> =nat
>
> ________________________________________
> 差出人: Drummond Reed [drummond.reed@cordance.net]
> 送信日時: 2008年12月5日 16:09
> 宛先: Sakimura Nat; 'Brian Eaton'
> CC: xri@lists.oasis-open.org
> 件名: 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
>
> ---------------------------------------------------------------------
> 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