Re: [cap-talk] Fwd: Seeking Feedback on Capability URLs Draft

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: [email protected] [mailto:cap-talk-
>> [email protected]] On Behalf Of Rob Meijer
>> Sent: Thursday, June 05, 2014 4:12 AM
>> To: General discussions concerning capability systems.
>> Cc: [email protected]; 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
>> [email protected]
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>