[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] trusted discovery workflow
Is not (hosting an) XRD a service itself, with it's own specified type? =peterd On Dec 5, 2008, at 11:36 AM, Eran Hammer-Lahav wrote: > (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 > > > --------------------------------------------------------------------- > 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 > Peter Davis: NeuStar, Inc. Director & Distinguished Member of the Technical Staff 45980 Center Oak Plaza Sterling, VA 20166 [T] +1 571 434 5516 [E] peter.davis@neustar.biz [W] http://www.neustar.biz/ [X] xri://@neustar*pdavis [X] xri://=peterd The information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this e-mail message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]