[cap-talk] Define petname - back up a bit, down to wording, recommendation?

[Jed Donnelley]

At 09:18 AM 2/24/2005, Ian G wrote:
>Jed at Webstart wrote:
>>At 09:10 AM 2/23/2005, Ian G wrote:
>
>>You refer to a "local and private resource".  Can't
>>that resource be a trust relationship?
>
>Well, let's back away here a bit and think about it.
>
>I'm thinking of it from the pov of a developer.  I want
>to build it.  ("what other perspective is there?")  So
>for me, a petname can only refer to a local defined
>resource, because a) it has to be stored with the
>petname to make any sense, and b) if it is not
>defined it can't be tractably stored.  So, a key, a URL,
>a domain, a hash are all starting points.
>
>Tyler is thinking of it from the pov of a user.  ("what
>other perspective is there?")  For the user, she sees
>the petname and thinks of ... whatever she thinks of.
>Which is the point, as she is concerned to map some
>simple thing (a name, a logo) to something complex
>("trust", a brand, a memory, a fear).

I believe we need to look at a feature/mechanism like
the "Petname" first from the perspective of the user.
Namely, we have to ask the question, does it provide
sufficient value to be worthwhile to the user.

>So when Tyler says the petname maps to trust, that's
>from one perspective.  The problem is, as a builder,
>I can't map that perspective to code.  All I can do is
>map the petname to a local resource.

I'm not sure I follow you.  I believe from the extensive
discussion we've had on this topic it is clear enough
that the Petname maps what you would refer to as
a "local" name to an entity - a Web entity.  The business
of associating trust or as some have noted distrust
or whatever with that entity is a process that the user
goes through.  Perhaps there are other means that
can/should/whatever be supplied to help users with
that process (personally I think that process is mostly
up to whatever Web entity it is), but whatever mechanism
that is the Petname per se is not involved.

>Now, if the user decides that mapping generates
>trust then well and good.

The user can and we rightfully will decide that the Petname
can provide trust for the binding at least, not for the
remote entity.  That is separate.

>But the user can decide
>that the mapping generates some other thing, like
>fear, brand, memories, reminders, etc etc.

That's fine and up to the user.  However, the user should
still be able to "trust" the binding of the name to
the Web entity.  Whatever the user feels about the
Web entity is up to the user.  I really hope we can
limit the Petname to solving the one problem that
it was intended to solve and separate out the other
aspects of trust relationships to another domain (in
the nontechnical sense of that term).

>Which then leaves open the question of whether
>the petname *only* maps to trust.  I don't think it
>can.  Even if we were to build it, it is up to the
>user to map it to trust.

I think the important distinction is between the "trust"
in the binding to the Web entity and any "trust" (or
distrust or whatever) in the entity itself.  *ALL* the
Petname does is to provide confidence in the binding
to the same Web entity that was being visited when
the Petname was assigned.  I don't believe anybody is
saying that the Petname does any more or less than
that.  I believe it can do that much within the limits of
the technical means we have (certificates and certificate
authorities, public key encryption, etc.).  What the
Petname does is to provide as much confidence in
such a name <-> Web entity binding as we can provide
with out technical means, no more and no less.

>>>Could you define relationship, and define trust?
>>
>>I think dictionary definitions suffice:
>>
>>1.  Relationship: a state involving mutual dealings between entities
>
>So, relationship could be "a set of dealings between
>two or more parties."

Correct.  In this case between a Web user and a Web
serving entity.

>>2.  Trust: Confidence based on past experience.
>
>2.a  Experience:  a judgment over a relationship.
>
>2.b  Judgement:  a compressed human opinion over
>a dealing or set of dealings.
>
>2.c  Trust:  an expectation that judgments over
>future dealings will match Experience.
>
>
>Which would lead me to suggest that while the
>machine can deal with relationship, and it may
>be able to record Judgement, it is less likely to
>be able to deal with Experience, and even less
>likely to be able to encompass Trust.

Wait, wait!  You now seem to be starting down
the road to again putting more into the Petname
that any legitimate role can have.  Remember, the
Petname can only help with the basis for the
relationship (by assuring that future interactions
are with the same entity so the relationship,
whatever it amounts to, can have the consistency
of at least the assurance that it continues to be
between the same two entities, the user and the
Web serving entity).

>Ergo, if a petname points *only* at Trust, this is
>all in the user's eye.

Yes, the trust is all in the users eye.  The Petname
only provides for the confidence and consistency in
the binding between the name and the Web entity.

>>>I for one generally try and eliminate trust from
>>>serious conversations as it quickly slips into a
>>>definition of "what I want it to mean" which then
>>>means we've moved over to selling, not building.
>>
>>I don't know, it seems pretty simple to me and has
>>nothing to do with selling.  Perhaps if you're concerned
>>about how to develop such trust, but there again that
>>isn't the business of the Petname but of the user.
>>The user develops trust in the relationship, the
>>Petname provides the best technical assurance
>>that we can provide that the relationship remains
>>fixed - i.e. the same one that we've developed the
>>trust in.
>
>Right.

Good.  Perhaps we're getting close to finishing our
beating of this horse?

>>>>When the user is deciding how to evaluate information or actions 
>>>>presented by a web page, only the trust relationship is relevant. In 
>>>>fact, the user should actively ignore the site's identity. The key 
>>>>question is whether or not the user has built up enough trust to 
>>>>authorize the site's use of a given personal detail.
>>>>
>>>>The situation is analogous to the way a capability OS implements access 
>>>>control. When deciding whether or not to grant a request, a capability 
>>>>OS does not consider the identity of the requestor, only whether or not 
>>>>the requestor possesses the required capabilities. Similarly, when 
>>>>deciding how to react to a web page, the user should not consider the 
>>>>identity of the website, only whether or not the trust relationship 
>>>>warrants the action. Think of a trust relationship as being like a 
>>>>C-list. A petname refers to a trust relationship in the user's brain in 
>>>>the same way as a pointer refers to a C-list in the kernel's RAM.
>>>
>>>Well, maybe.  We want the petname to refer to that
>>>relationship, but we cannot guaruntee that it does.
>>>About all we can do is guaruntee that a petname
>>>refers to a key, and a key has been used before.
>>>And even that is challengable at the margin.
>>
>>I'm not sure what you're questioning.
>
>
>I'm questioning whether a petname can only bind trust.
>
>We are coming out of a decade where VeriSign said
>that using its certs gave you trust.
>
>They are two very similar statements, with very similar
>shortfalls in usability.

I do think the issues are quite similar.  I certainly don't want to defend
Verisign and buy into or feed into the claims that they might make
for marketing reasons, etc.  However, in the case of Petnames I hope
we can, ultimately (whew!), agree on language that will define exactly
the value that they provide - confidence in the binding between the
name and a Web entity that can provide the basis for a developing
relationship between a user and the entity.  The Petname provides
confidence that the entity remains unchanged (e.g. due to phishing)
during the course of the relationship.

...
>Yes.  How about:
>
>The Petname mechanism is a tool that allows users to associate a
>name (the "Petname") with a safe binding to a known _resource._
>This can help users avoid "phishing" attacks
>_by safely binding a name to a known website._
>If a user sees a bound Petname in the toolbar they can have confidence
>the site they are communicating with is the same organization that they gave
>the Petname to.  The Petname tool can help users build up relationships
>_about/of trust_ with organizations on the Web.
>
>My changes _emphasised_.

The meaning of the above is fine to me.  I hope we are now into a phase
where we are agreed on the value of the Petname (in the limited form
that we've finally honed it down to) and can work on getting some wording
to express that value - e.g. for others in a recommendation.