- From: Rob Meijer <rmeijer@xs4all.nl>
- Date: Sat, 7 Jun 2014 09:07:40 +0200
- To: "General discussions concerning capability systems." <cap-talk@mail.eros-os.org>
- Cc: "www-tag@w3.org" <www-tag@w3.org>
Hi Alan, B.t.w, how is Marc S and your work on the RFC getting along? https://groups.google.com/forum/#!topic/friam/PTivwfg93Tc That work it seems may be very relevant for what w3 is trying to do here? Rob On Thu, June 5, 2014 17:06, Karp, Alan H wrote: > Rob Meijer wrote: > > an excellent response. I'd like to note that >> >> 4) Regarding the canonical URL, there is the issue that there may be >> multiple paths to derive a capability to a resource that grants >> attenuated >> access.For example a file-system tree shaped graph may allow >> decomposition >> and for example read-only attenuation. If Alice decomposes the tree, >> delegates a branch to Bob who than creates a read only attenuation of >> the >> branch and gives this to Carol. Alice also creates a read-only >> attenuation >> of the whole tree and delegates that to Dave. Now Dave decomposes the >> attenuated full tree, delegating it to Carol. If Carol is to determine >> that the authority that Bob delegated to her is exactly the same as what >> Dave delegated, that means that attenuation of decomposition should >> yield >> the same capability URL as the decomposition of attenuation. >> > is not a requirement. You rarely care if the two references are to the > same object. > > Like capabilities passed through a membrane, E-speak had the "problem" > that Carol would get different capabilities in this scenario and would > have no indication that they referred to the same object. That worried > some of our customers, so we implemented the Ask Bob protocol. (Where the > name comes from is a funny story.) To the best of my knowledge, nobody > ever used it. > > ________________________ > Alan Karp > Principal Scientist > Enterprise Services, Office of the CTO > Hewlett-Packard Company > 1501 Page Mill Road > Palo Alto, CA 94304 > (650) 857-3967, fax (650) 857-7029 > http://www.hpl.hp.com/personal/Alan_Karp > > >> -----Original Message----- >> From: cap-talk-bounces@mail.eros-os.org [mailto:cap-talk- >> bounces@mail.eros-os.org] On Behalf Of Rob Meijer >> Sent: Thursday, June 05, 2014 4:12 AM >> To: General discussions concerning capability systems. >> Cc: dan@torgo.com; www-tag >> Subject: Re: [cap-talk] Fwd: Seeking Feedback on Capability URLs Draft >> >> Some more concrete feedback: >> >> Intro: '2' in the case of an 'unguessable' URL is in fact an example of >> '1', 'the correct token'. If you want to talk about the scenario's in >> terms of security tokens, I thing the best distinction is: >> >> 1) The use of 'authentication' tokens. Passwords are an example of >> these. >> 2) The use of 'authorization' tokens. >> A) The use of non designating authorization tokens. >> B) The use of designating authorization tokens. >> >> If we take the standpoint that all security tokens should be >> 'unguessable', than the use of capability URLs is an example of 2B. Some >> uses of cookies can be seen as examples of 2A. >> >> Regarding section 3: >> >> I believe the whole section 3 is rather biased towards the use of >> identity >> in applications. There are many issues with the undue use of identity in >> many forms and there are many security issues that can arise from the >> use >> of identity and/or the lock-in to a granularity of individual users. >> If using capability URL reduces the undue use of privacy sensitive >> and/or >> decreases the use of granularity locked access control, than its use has >> a >> major positive impact on the overall security properties of the >> system(s) >> involved. There are major gains to had from the use of multi granular >> access control models that don't yield any special lock-in to a single >> granularity, that of the user account. And this is still very much >> separate from the issues with federated identity management. Issues that >> I >> think the Zebra Copy paper shows that even in situations where identity >> is >> relevant, the separation of authentication and authorization yields >> important properties that benefit the manageability of distributed >> security attributes. >> >> A further issue comes with the idea that a client should always >> authenticate, and that the end of session should mean the capability >> should get automatically revoked. A useful pattern of use is for example >> that a user might authenticate herself in order to than delegate some >> authority to a client by giving that client a revocable capability that >> it >> can use until for example it is explicitly revoked. There are two >> important properties to >> the use of authorization tokens over authentication tokens: >> Authority can be decomposed and/or attenuated. If I grant attenuated >> decomposed access to a resource to a client by delegating a capability >> to >> it, that client will only ever have access to the delegated attenuated >> chunk of the decomposed authority. If I grant the client access to my >> log >> in credentials, I'm effectively delegating all the authority tied to the >> account to the client. Hardly a secure idea. >> >> As for the recomendations: >> >> 1) The base recommendation is simply horrific and anti-productive. In >> the >> sentence 'The use of capability URLs should not be the default choice in >> the design of a web application because they are only secure in tightly >> controlled circumstances', you could replace 'capability URLs' with any >> of >> the following concepts and end up with a stronger case: >> >> * passwords >> * cookies >> * log-in credentials >> * identity >> * unattenuated authority >> * single granularity abstractions >> >> Given the alternatives, IMHO the use of capability URLs "SHOULD" be the >> default choice in the design of a web application. >> >> >> >> 2) Capability URLs should expire. This one is tricky. If the capability >> implies very limited attenuated authority, than the act of >> re-authorizing >> a client using a much more powerfull capability or using log-in >> credentials may in many cases constitute a much larger risk than >> allowing >> the capability to remain valid. >> >> 3) There are quite some good practices missing, ,ost notably the use of >> fragments for encoding the unguessable part of the URL. >> >> >> http://waterken.sourceforge.net/web-key/ >> >> >> 4) Regarding the canonical URL, there is the issue that there may be >> multiple paths to derive a capability to a resource that grants >> attenuated >> access.For example a file-system tree shaped graph may allow >> decomposition >> and for example read-only attenuation. If Alice decomposes the tree, >> delegates a branch to Bob who than creates a read only attenuation of >> the >> branch and gives this to Carol. Alice also creates a read-only >> attenuation >> of the whole tree and delegates that to Dave. Now Dave decomposes the >> attenuated full tree, delegating it to Carol. If Carol is to determine >> that the authority that Bob delegated to her is exactly the same as what >> Dave delegated, that means that attenuation of decomposition should >> yield >> the same capability URL as the decomposition of attenuation. >> >> http://minorfs.wordpress.com/2014/03/21/rumpelstiltskin-and-his-children- >> part-2/ >> >> >> _______________________________________________ >> cap-talk mailing list >> cap-talk@mail.eros-os.org >> http://www.eros-os.org/mailman/listinfo/cap-talk > > _______________________________________________ > cap-talk mailing list > cap-talk@mail.eros-os.org > http://www.eros-os.org/mailman/listinfo/cap-talk > >
Received on Saturday, 7 June 2014 07:08:13 UTC