[cap-talk] struggling to learn what techniques supplant passwords
seth.purcell at sitelier.com
Thu Nov 3 08:19:08 PDT 2011
From: cap-talk-bounces at mail.eros-os.org
[mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jonathan S. Shapiro
Sent: Wednesday, November 02, 2011 5:56 PM
To: General discussions concerning capability systems.
Subject: Re: [cap-talk] struggling to learn what techniques supplant
On Wed, Nov 2, 2011 at 9:08 AM, Seth Purcell <seth.purcell at sitelier.com>
>>There's no getting around it - unless the user can remember his entire
>>caplist, he needs some kind of master cap, which holds all his authority.
>>And unless he can remember this cap's web-key, it needs to be stored
>>somewhere - either as a browser bookmark a la Waterken, or on a sticky
>>on his monitor at home, or on the app server behind a password dialog. You
>>can trade off accessibility and usability for vulnerability, but you can't
>>get rid of the problem.
>Nobody in the cap community has said otherwise.
>Somewhere along the way, I think you got the idea that capabilities
eliminate the need for authentication.
On the contrary, I was suggesting password-based authentication as a
pragmatic solution for connecting a user to his caps without tying him to a
>This isn't true, and I don't think that anybody here would claim that it is
You appear to have misinterpreted my somewhat ab initio reasoning at several
points, thinking we disagree where we do not.
But since you raise the point, I'd like to ask the list in general:
Isn't a username/password pair really just a master cap key in a different
form, one that's designed to be memorable as well as unique? Isn't the only
reason we consider it "authentication" really just the belief held by the
server that it suffices to establish identity with some degree of
confidence? These "credentials" are certainly readily shared, along with the
attendant authority, just like a cap key.
Conversely, if you hold a Waterken web-key bookmark that the server believes
is never shared, isn't visiting that URL now sufficient to establish
identity with a reasonable degree of confidence, from the server's point of
I may be treading well-worn ground here, but to me, arguing about whether a
particular interaction is "authentication" or "authorization" is purely
server-side semantics - we have ample precedent for credentials being
shared, and caps being used to establish identity.
To really drive the point home: when a new user signs up you could assign
him a unique random password. When he logs in, he only enters the password -
no username. In fact, let's say he takes a shortcut and doesn't even use a
form - he just goes to /login/his-password. This is now obviously the exact
same *mechanism* as a master web-key. The only difference in whether we
consider this to be an authentication event or an exercise of authority
without identity is, bizarrely, what the server decides to do - associate
the user with a known identity? Then it's authentication. Invest the user
with authority? Then it's authorization. In practice, it's usually some
combination of the two.
To me, these interactions seem suspiciously like vectors comprising two
orthogonal components: authority and identity. That is, any given
interaction is movement in a conjoined "identity-authority" space. Whether a
particular interaction is considered "authentication" or "authorization" is
then a matter of emphasis, not kind. Space-time intervals can be space-like
or time-like, but they're all intervals in space-time.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cap-talk