[cap-talk] Petname Tool at W3C workshop
tyler.close at gmail.com
Thu Feb 16 19:51:57 EST 2006
On 2/16/06, Jed at Webstart <donnelley1 at webstart.com> wrote:
> At 11:13 AM 2/16/2006, Tyler Close wrote:
> >Hi all,
> >My paper on the Petname Tool for the "W3C Workshop on Transparency and
> >Usability of Web Authentication" was accepted. The workshop home page
> >The paper I submitted is at:
> >The paper includes an acknowledgment for the contributions of the
> >members of the cap-talk mailing list. Thanks again for your help
> >developing the Petname Tool.
> I read the above paper with interest. Short and sweet.
Your feedback has been especially important, so thank you Jed.
> There are a couple of points I'd like to understand about the "A step further"
> section where you discuss:
> "A further step would be to bind authorization tokens, such as passwords,
> to the cryptographic designator of the site they should be submitted to."
> Did you intend to refer to passwords as "authorization" tokens
> rather than as "authentication" tokens?
;) I waffled on this line for a while. I wanted to leave myself a
segue to talk about capability URLs (or password capabilities) at the
workshop if the opportunity arose.
> Was that intended as something
> of a dig at ambient authority sorts of authorization mechanisms where
> there is first an authentication to identify the user (ambient authority)
> and then a separate mechanism to determine the authorizations of
> that user?
No, it wasn't a dig. I thought referring to a password as an
authorization made it more natural to suggest that it is something
that needs to be bound to a particular server. An authentication is
not something that you bind to a particular correspondent. For
example, an SSL client certificate may be used across multiple
> Then when you describe a mechanism where a "...browser's password manager
> should generate passwords on behalf of the user and autofill login forms with
> the user's username and password.", I wonder how the username gets created
> with such a mechanism. This has always seemed an awkward situation to me,
> particularly with regard to conflicting names. Since I consider the username
> superfluous, I find it particularly irritating.
Yes, there are all sorts of implementation nits in terms of how you
collect, generate and store the username/password information. I
believe Ping is writing a paper about how that could be done. He
already has a blog entry with some of the details:
My W3C paper is primarily about the petname tool. The short "A step
further" section is just there to answer the expected complaint of
"users will just ignore it", to indicate that there are enhancements
being worked on, and to provide a segue to cap URLs.
> I wonder why you didn't plug your YURL scheme in the above? Isn't it really
> something like a YURL that the user (the person, not the computerized
> "username") needs for remote authorization?
Yes, but I don't think I'll be able to cover that much ground in one
workshop. I'll certainly give it a shot if it looks possible. My more
realistic goal is just to get people thinking in that direction by
learning the simpler petname concept. For now, it looks like I'll have
my work cut out for me with even this less ambitious goal. The world
still seems to be enthralled with the idea of a highly certified
global namespace. See:
> With such an approach there is no 'username'
> needed. Any binding to a person happens directly to the person, e.g.
> with their
> real name, perhaps address, etc., rather than binding through an intermediate
> 'username' that can often times be a source of confusion (e.g.
> conflicting names)
> but to my understanding provides no value in itself.
> One other minor point about the paper (perhaps it isn't in final
> form?): I have always
> thought it a good idea to spell out technical abbreviations once in
> such papers.
> The one that struck me was UI - User Interface. Next might be SSL - Secure
> Sockets Layer. Maybe WWW and URL are enough in the language these days
> that they don't need to be spelled out when first used in a
> paper? If there's a common
> style for such technical abbreviations these days I'd like to hear about it.
I'd just assumed that UI and SSL were also familiar acronyms for the
readers of this paper. No harm in spelling these out though. I'll do
that. I'll probably send in an update towards the end of next week.
Let me know if you see any other clarifications to be made.
The web-calculus is the union of REST and capability-based security:
Name your trusted sites to distinguish them from phishing sites.
More information about the cap-talk