RE: [xri] trusted discovery workflow

[Sakimura Nat <n-sakimura@nri.co.jp>]

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