Re: Secure Metadata

I agree that the signalling "we've been here before" (where the
notion of "here" can quite possibly be detached from a domain
name, and refer to the organization, as Petname shows) is
something that browsers can do based on today's infrastructure.

I would be curious to see some testing how petnames compare to
logos in terms of usability and recognition -- do people
recognize the names they gave better or worse than logos? How
do the warn signals mix with visually strong branding and
possibly compelling phishing stories?

Also, in the petname setting, linking an online experience with
offline brands continues to be a matter of looking at web site
content, and ultimately taking things at face value.  The
padlock may have been intended as a poor man's online version
of the credit card logos that an offline shop displays, but it
doesn't serve that purpose.

Secure metadata could help to display that information at a
browser level: It may quite possibly turn out that there is a
useful mix of well-known branding displayed properly -- note
that there is a gatekeeper in this scenario --, and metadata
that abstract away a bit from the site's identity and talk
about the properties of that site that the user may need more
urgently than its identity -- "this is a bank", "verified by
lordcard", "certified lunch club merchant", etc


Besides the question of whether there is enough interest in
this general direction, we have to look at the scope question.

Would people here be satisfied with a lightweight effort that
(as suggested by Michael) initially just looks at the question
that George asked: The logotype extensions of which
certificates can sites epxect browsers to display?

Or should formal work in this area immediately go towards more
heavyweight trust labels, and the formats related to these?

-- 
Thomas Roessler, W3C   <tlr@w3.org>





On 2006-04-12 11:47:59 -0700, Tyler Close wrote:
> From: Tyler Close <tyler.close@gmail.com>
> To: public-usable-authentication@w3.org
> Date: Wed, 12 Apr 2006 11:47:59 -0700
> Subject: Re: Secure Metadata
> List-Id: <public-usable-authentication.w3.org>
> X-Spam-Level: 
> X-Archived-At: http://www.w3.org/mid/5691356f0604121147u53a41317wb3e119fa0d423c40@mail.gmail.com
> 
> 
> On 4/12/06, Michael.Mccormick@wellsfargo.com
> <Michael.Mccormick@wellsfargo.com> wrote:
> >
> > RFC 3709 (http://www.ietf.org/rfc/rfc3709.txt) defines an X.509
> > extension that allows optional logographic images for community, issuer,
> > and subject organizations.
> >
> > Say for example GM obtained web server SSL certificates from VeriSign
> > for use within their supplier community.  The cert could display logos
> > for GM, VeriSign, and the auto parts exchange (or any subset /
> > combination thereof).
> 
> The above scenario involves the repeated use of existing
> relationships, in particular, the relationship between a supplier and
> GM. To protect against phishing in this scenario, it is important that
> the supplier's employees be able to readily recognize when they are
> using this longstanding relationship versus when they have encountered
> a stranger. For this scenario, we don't really need more bits in the
> certificate, we just need to do an equivalence test on the presented
> certificate.
> 
> If you step back and think about it, putting an image in the
> certificate is just putting more bits in the certificate for the user
> to compare to a known value. Users shouldn't be comparing bits, that's
> what computers are for. The computer should compare the bits and tell
> its user whether or not they match any of the user's known sites.
> 
> The Petname Tool moves the comparison burden from the user to the browser.
> 
> Tyler
> 
> --
> The web-calculus is the union of REST and capability-based security:
> http://www.waterken.com/dev/Web/
> 
> Name your trusted sites to distinguish them from phishing sites.
> https://addons.mozilla.org/extensions/moreinfo.php?id=957
> 
>

Received on Friday, 14 April 2006 16:23:59 UTC