[cap-talk] Webkeys vs. the web

[sw at tiac.net]

Would it be a proper use of the ERights wiki to put up a page
on this topic?  Does that sound worthwhile to the rest of you?

I am thinking of a list of use- and abuse-cases, each with
questions like, scenario(s) where it would come up?  ways of
dealing with it (whether preventing or enabling)?

Is a "whiteboards" section on wiki.erights.org a good idea?

I have been following the webkey discussion at skim level.
My eyes blur without a static picture to orient to.

As I wade into this, I notice a distinction between
     1) the basic necessary properties of browsers (mainly)
        to enable useable safe human and machine sharing of caps
        over the web, vs.
     2) a host of issues beyond browser behavior, that would have
        to be solved to make the human version actually happen
        and correctly.

Occurs to me that not only does one need to
watch out for what users might do, and of course attempted
click-jackers, but also what well-meaning but human web
developers might do.  Or else somehow we need capabilities
that can *only* (up to of a certain level of web programmer
fumble) be shared with something like a distinctive
Share dialog box (and unlike with readable or writeable files,
must we trust the web programmer to correctly describe the power
each capability provides...or perhaps every capability has
a method to describe its powers in human terms?)

Given that authority-granting choices
should be presented clearly to the first user, then if that
user delegates something to another *person*, the same
sort of care would seem appropriate when presenting delegation
choices to the second user, and so forth.  Also, perhaps
human-delegated caps should be revocable and distinct per
delegation act.  Is it possible to avoid the issue of
managing for a user the capabilities they have given out?

If I want to share a cap with
a friend, but paste the url into an email, t'were best if that
url only work for that friend lest I inadvertently send to the
wrong friend.  Probably the intended friend should go through
some dialog box to put the url into use.  This implies a protocol
involving both people's computers, and human-identifiers.  Right?
If Bob the human wants to pass to Alice the human, his computer
needs a concept of Alice-receiving-a-capability?

A webkey that would have limited powers unless
used with a certain cookie present...sounds useful
to me but probably has drawbacks.  Anyhow it could be a
true capability: it could represent an object that would
behave differently if primed with the cookie.  The cookie
and the URL could have a one-to-one relationship, and both
the cookie and the object's activated mode would expire.
The use I am thinking of is that the URL is only powerful
in the browser-session it was created for.
And how much to mute its default behavior?  404 Not Found?
Link to the web site?  Some not-user-specific, but topic-
specific page?  Read-only link to the account?  This is all
to deal with the case of the user engaging in some
deprecated URL-diving behavior.  The approved alternative being
to present these options in a Share-dialog-like thing.

If I clone-and-mutate keys every time I delegate,
they must live on the server, right?  But if so, how can they
be managed on behalf of the human user (not to mention remote
client software) in a way that's coherent for the user across
all the websites he visits?  (Yuck.)

Anyway, what about that wiki page?  I was able to
create an account and http://wiki.erights.org/wiki/SteveWitham

  --Steve Witham
P.S. speaking of forwarders,
tinyurl had a server problem today (fixed, e.g.,
http://tinyurl.com/fwusb320 ) and I got a rational response
to my problem report, seemingly from (one of) the founder(s).