[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] trusted discovery workflow
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]