[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] RE: Delegation (was: trusted discovery workflow)
This makes sense to me, but I think the challenge is how to codify this behavior in a way that is easy to understand and implement... It is way too easy to screw this up. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, December 05, 2008 9:58 AM > To: Eran Hammer-Lahav > Cc: xri@lists.oasis-open.org > Subject: Re: [xri] RE: Delegation (was: trusted discovery workflow) > > On Fri, Dec 5, 2008 at 9:46 AM, Eran Hammer-Lahav <eran@hueniverse.com> > wrote: > > A domain delegating the management of their services to a third > party. Hosting and managing XRDs can and should become a product. Of > course, if you <ref> the entire XRD, you can as easily just point the > Link in that direction in the first place but it only works well with > Link header and element where you have a resource level control. If you > use a /site-meta map, it is impossible to point some XRD locations to > server A and some to server B (at least this is a use case I refuse to > support due to complexity). I much rather allow this to happen using a > simple <Ref> in the local XRD itself. > > This sounds like a reasonable use case, and I think it'll fit into the > trust workflow. > > - If the initial XRD is not signed or does not delegate to a new key > in the trust chain, the next XRD must be signed with a key > authoritative for the initial XRD. More concretely: if I don't > specify that somebody else can sign an XRD for me, that next XRD needs > to be signed by me. > > - If the intial XRD is signed, it can point to a new key that will be > used to sign the next XRD.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]