Capability development principles (was Re: [cap-talk] YURLs. What is the model of development?)

[David Chizmadia (JHU)]

David Wagner wrote:
> David Chizmadia writes:
>>From: "Sandro Magi" <smagi at naasking.homeip.net>
>>> Is it possible to interject some sort of authentication step before a 
>>> capability request is satisfied? In explaining the web-calculus to 
>>> others, they've often expressed dismay that the unguessable URL is the 
>>> only authentication required to access a resource. Their main concern is 
>>> that a user might inadvertently leak a URL to a third party who 
>>> shouldn't have access to the resource.
>>
>>    Of course, the underlying problem is a complete failure on 
>>the part of those looking for the extra authentication to 
>>understand the concept of capability discipline, but if this 
>>provides comfort, it is worth it.
> 
> I don't understand your comment.  This is not about comfort and warm
> fuzzies.  This is about what seems to me to be a valid real-world concern.
> Framing this as about "comfort" leaves the impression that you consider
> this to be not a real problem and the questioner not thoughtful enough
> to understand why.

    I agree that it is a real concern in terms of tradeoffs, but it
is indeed the case that the questioner has either not thought through
or not asked enough questions about the principles of capability 
discipline. Caveating that I'm referring to object capabilities
here, my understanding of those principles is as follows:

  * An object capability contains both the designation (name) of
    a resource and the authority required to access that resource;

  * Possessing the capability, such that it can be presented to the
    resource server, is the only necessary and sufficient condition 
    for actually getting access to the resource;

  * Revocation and additional accountability are accomplished through 
    the careful use of facades (membranes?);

    As with all security architectures, capability discipline implies 
certain obligations on the capability wielder (i.e., client). When 
these obligations cannot be met in a particular environment, the 
security architect must reconsider the use of capabilities. (When 
doing so however, the architect will often find that other approaches 
actually impose the same obligations on the client and are therefore 
no more or less effective.)

> If the goal is to see capabilities more widely used,
> this kind of response seems, quite frankly, more likely to put people off
> than to win converts.

    I agree, but I was speaking to someone who appears to have 
been a convert longer than myself, so I was considerably more 
blunt than I would be with someone I was trying to convince.

> I'd think that patient education and explanation of your preferred 
> solution is going to be a lot more effective than telling people 
> they don't understand capability discipline.

    Absolutely! I do find the comment somewhat ironic since 
education and explanation is usually only required when a 
person does, in fact, not understand something; otherwise,
it is either being pendantic or more correctly characterized
as arguing architecture ;-)

> Perhaps you could
> explain what is a better solution to this problem that is more in keeping
> with capability discipline.  I like to think that anyone who is reading
> this list is likely to be interested enough to listen to your preferred
> solution, and thoughtful enough to have the capacity to understand.

    I was having trouble understanding the first sentence, when I 
realized that the quote above dropped my statement that the solution
to the originally stated problem is to use the SSL protocol (which is
an integral component of HTTPSY) in mutual authentication mode. I 
assert that this would provide all of the advantages of passwords 
with greater assurance.

    Looking at the problem from a "pure" capability perspective, the
more correct solution would be to require the server to hand out a 
different YURL to each unique client and keep a record of what known 
characteristics of the client make that client unique to the server. 
Then, when the YURL is presented to the server for access, the server 
can check the known characteristics of the client presenting the YURL
against its record for the client that was given the YURL. If the 
server had required client login, then it would make perfect sense to
use that login information as a unique characteristic.

-DMC