[cap-talk] back to: First point of consensus

Jed Donnelley jed at nersc.gov
Fri Feb 11 12:56:49 EST 2005


At 03:33 AM 2/9/2005, Ian G wrote:
>Jed at Webstart wrote:
>
>>At 04:31 PM 2/8/2005, Ian G wrote:
>>...
>>
>>>However, I suspect none of this reaches the realms
>>>of practicality until it is decided what the basic
>>>unit of trust is going to be in the browser.  Right
>>>now it might be an x.509 key.  Other proposals have
>>>been made.
>>
>>Why does this concern you?  Go ahead and use an x.509
>>key now and adjust to something else later if it comes
>>along.  Where's the problem?
>
>Well, the issue is that "how the petname
>gets added in and used" is somewhat or
>highly dependent on how the naming or
>pointing is done.

Certainly binding the Petname to a pointer
of some sort (keys I think you call them in:
http://www.erights.org/elib/capability/pnml.html
) is dependent on the nature of
the pointers.  There has to be an interface
that supports such bindings.  However, if
the binding is to a URL now and to a
YURL or a fingerprint later - it seems to me
that the base Petname mechanism still
adds value (at least it's much less likely that
there will be confusion in linking through a
Petname - even if what it's bound to is
questionable).  As David Wagner noted elsewhere,
it's important to make progress even if we have
to do it one component at a time - and we do!
Maybe the pointers will ultimately be capabilities
of some sort, but the value of the Petnames
remains to begin with and will only increase in
value as what they are bound to gets tightened.

>In software engineering
>terms, first we would decide on what we
>are doing w.r.t. Zooko's triangle, and later
>on we would fill out the gaps with (potentially)
>petnames.  Mark Miller makes the point that
>petnames is a device to bug fix the ZT law.
>First comes the ramifications of that, and
>later on comes petnames.

We can respectfully disagree about how best
to improve the real world.  I expect you won't
get past "first we would decide" any time
soon - especially given that we can seem to
even get past this First point of consensus.

>Yet, I gather the petname concept is not
>intending to use x.509 certs.  Which means
>there is a whole naming infrastructure to
>create and put in place.  That looks like a
>pretty tall order to me.

It doesn't seem to bad to me, but we can deal
with it when we get there.

>>>Unfortunately, we can't see enough
>>>into the future to be able to decide how that is
>>>going to play out,
>>
>>You seem to be able to see far enough to see
>>value in the name/identity binding that the Petname
>>mechanism adds.
>
>Yes, I've seen the proposal - near enough -
>in other proposals.  It's an important element
>in a cohesive strategy, but it's just one element,
>and I wouldn't rely on it alone, as is being
>suggested here.  That doesn't make sense in
>security systems.

Who is suggesting that it be relied on along?
It is being suggested that it adds value.  Moreover
I argue that it adds value independent of the other
components that it is combined with - though of course
it's particular form (e.g. GUI, whatever) might be
criticized/tuned, etc.

Let's agree that this much adds value and make that
notion available to whoever might want to pick up on it.

>>You seem to see far enough
>>ahead to see value in the "YURL" (fingerprint or
>>the like) addition to a URL to get a positive ID
>>to bind with the Petname.  Isn't that enough to
>>move forward?  Why wallow in the ambiguous
>>and clearly error prone present when we can
>>see technical improvements - if we can get
>>a consensus...
>
>No.  I'm comparing the Petname proposal
>to a few other proposals.  I think the other
>proposals have more merit.

If they address the same base problem (basically
name ambiguity as I see it), let us know what they
are and perhaps we can debate their relative merits.
I'll be interested to hear.  The Petname idea (perhaps
I don't understand how much is implied by the name)
seems generic enough to me (more or less binding
between what's referred to as "Lambda&Pet Names"
and the "Keys" in the Zooko's triangle diagram:
http://www.erights.org/elib/capability/pnml.html
) that I see value in that generality.

>>>so until we do know, John Halleck's criticism rules, IMHO.
>>
>>
>>Which criticism was that?  Perhaps this one?:
>>
>>Halleck: "It is a nice discussion, but baring smarter users,
>>I think it is theoretical..."
>
>
>! Yes it was that, but I read it as "baring lots of things"
>it remains theoretical.

 From my perspective a general mechanism seems to head
in the direction of solving a problem then it's time to get some
implementations out there and tune things like user
interfaces.

>>I don't see anything limiting the Petname mechanism and what
>>is essentially the YURL mechanism to the 'theoretical' in the
>>absence of smarter users.  Both seem to me to add value
>>for smart or not smart (perhaps kinder would be experienced
>>or inexperienced) users.
>
>There are about 500 million users out there,
>with most of them having browsers.  To date,
>we have gone through a period of approximately
>6-7 years with no change to the browser market.
>The current state of the browser market is that
>it accepts no changes and no responsibility for
>the phishing thing.
>
>Others have tried to do what the petname thing
>tries to do.  There is experience out there in the
>market in doing this.  If that experience isn't to be
>tapped and recognised, then I personally would
>look for something magical in the marketing that
>allows it to overcome the market barriers (for
>example, Netcraft).  I've not seen anything like
>that, so I'd say that the proposal will be stalled
>at the theoretical / demo level.

Perhaps so, but that shouldn't stop us for agreeing
that it seems to solve the one problem, recommending
it, and doing what we can to get implementations
out into the wild.

>That's no bad thing, there are probably a hundred
>other proposals at that point.  Every man and his
>dog is trying to solve this phishing thing.  Petnames
>proposal has the merit of 99% of the others that
>the issue is in the browser - user interface.  But
>there are others out there that have figured that
>out too.

Please suggest specifics so that we can decide if
our "First Point of Consensus" might be misplaced.
I agree with Ben Laurie's original point that if we can't
decide on specific approaches that seem to be promising
to pursue to solve specific problems then it seems we are
doomed to wallow around wasting our typing.



More information about the cap-talk mailing list