Re: [xri] RE: Delegation (was: trusted discovery workflow)

[Ben Laurie <benl@google.com>]

On Fri, Dec 5, 2008 at 6:24 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> 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.

It seems quite simple to me. At any point I have a current authority,
and until I hit an XRD signed by that authority, it doesn't change.
When I do, it becomes whatever the new XRD specifies. When I reach the
end, the current authority must be authoritative for whatever resource
I end up with.

I do worry, though, that there could be some kind of attack where
(forged) unsigned delegations are used to point some service at the
wrong endpoint in the same domain, with the result that Bad Things
happen.

>
> 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.
>
> ---------------------------------------------------------------------
> 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
>
>