RE: petname implementation recommendation proposal

Hi Rachna,

Obviously I believe more can be done to improve the petname tool, since I've also proposed a way of integrating it with the form filler. My understanding is that the group didn't feel we could complete work on that integration for June, but might be able to do the petname tool in isolation and that doing so might provide some advantages. For all its shortcomings, I think the petname tool is still clearly better than a hostname display and is more "cognitively scalable" than a hostname display. Typing in, and recognizing, my own mnemonic for an entity is easier, for me, than remembering all the various hostnames that an entity may use, and performing a careful character-by-character match against the hostname display. I would be surprised if there were usability studies contradicting this experience. From what I've read, just performing the character-by-character comparison is very difficult for a human, let alone remembering what string they are supposed to be comparing against. From what I've learned about usability, the hostname display seems to require many of the skills that humans don't possess. I think the petname tool makes fewer poor assumptions. I think integration with the form filler can address the remaining poor assumptions. Even if the latter point doesn't bear out, the petname tool is still an improvement upon our existing identity signals.

--Tyler

________________________________
From: Rachna Dhamija [mailto:rachna.w3c@gmail.com]
Sent: Tuesday, March 18, 2008 6:33 PM
To: Close, Tyler J.
Cc: Thomas Roessler; mzurko@us.ibm.com; public-wsc-wg@w3.org
Subject: Re: petname implementation recommendation proposal

Sorry to ask a question that seems indirectly related to this thread, but it seems like a good place to ask a process question.

It seems that we've been able to successfully raise technical issues against proposals (e.g., how to bind a petname to a public key).  This is good as it results in discussion and then iteration of the proposal.  But we do not see as many usability issues being raised against the proposals.  For example, with petnames, I think before we even debate implementation details, I would question the cognitive burden that it places on users.  It requires the user to take extra effort in coming up with a petname for a site, entering it, and then noticing and recognizing it in the future.  This is not "cognitively scalable".

Would it be helpful if we raised usability concerns as "issues" against proposals, rather than having them live on a lonely page on the wiki?

and Tyler, forgive me for using your proposal as an example, but I think I've made these points before.  You deserve lots of credit for being innovative, responding to the group's concerns and iterating.

Rachna

On Fri, Mar 14, 2008 at 4:23 PM, Close, Tyler J. <tyler.close@hp.com<mailto:tyler.close@hp.com>> wrote:


I wrote:
> My memory of the last round of discussion is that the
> controversial techniques were: determining a correlation
> between cert chains based on reuse of a public key; and
> assuming the tuple (CA cert, end-entity DN - CN) is a GUID. I
> think there are still interesting proposals to be made that
> don't use these techniques. We could try another round of
> discussion on a proposal that doesn't use either of these
> techniques. Is that what you want to do?

I've worked up a rough outline of what a petname implementation recommendation could look like. Since looking at information in an X.509 certificate other than the host identifier generates controversy, I'll instead propose a petname implementation that relies solely on this information:

If the current web page is "strongly TLS-protected", the user may assign the authenticated entity a petname. If the web page uses a "validated certificate", this assignment MUST create a binding from the petname to each of the host identifiers the certificate is valid for. These identifiers are found in the CN attribute and the subjectAltNames attribute, as specified by HTTPS. If the web-page uses a pinned self-signed certificate, this assignment MUST ONLY create a binding from the petname to the pinned destination.

When browsing a "strongly TLS-protected" web page, the petname presentation MUST present the petname corresponding to the host identifier specified by the dereferenced URL.

When comparing host identifiers, the petname presentation implementation MUST use the same algorithm used by HTTPS, in particular, a wildcard match MUST be supported where HTTPS would support it.

The petname presentation MUST support renaming and deletion of a petname binding.

When the user assigns a petname, the petname presentation implementation MUST warn the user if the chosen petname is similar to one currently in use. The meaning of similar is up to the implementation, but MUST at least include an identical petname.

--Tyler