[cap-talk] A palatable solution?

[Sandro Magi]

Sandro Magi wrote:
> I'm envisioning now a single sign-on e-mail system which can provide 
> this for you. MarcS might be slightly miffed since it would require an 
> initial login (when on a non-trusted computer), but it can hold all of 
> one's capabilities and produce one-time versions on demand.
> 
> You'd explicitly add a list of YURLs to the account when at home; they 
> are thus classed as capabilities and protected accordingly. When "on the 
> road", everytime you sign in to the account and attempt to access those 
> YURLs, it produces a membrane for you and proxies requests.
> 
> Alternately, it could accept 2 YURLs: one to the original resource, and 
> one to a single-use membrane service on a different server (preferably 
> the one specified in the first YURL); your trusted proxy would generate 
> a membrane and return the single-use YURL to you on the untrusted 
> client. That seems the most scalable option.
> 
> YURLs would never be visible when authenticating by login (only the 
> membrane YURLs are visible). YURLs may be visible when accessing the 
> trusted proxy by YURL.
> 
> This is actually starting to sound similar to what others have 
> recommended earlier. Apologies if I just didn't understand them at the 
> time.
> 
> I'd really appreciate comments on this, particularly harsh criticisms if 
> it's blatantly wrong somehow.

I would like to further add that attaching capabilities to e-mails is 
trivial in this system, and they are never divulged in over-the-shoulder 
attacks.

If the e-mail is being sent to a user on the same system, the YURL 
itself need never be exposed in the message. If it is destined for 
another system:

1. it can be wrapped in a standard envelope identifying it as a YURL (in 
conjunction with a server-side petname markup language implementation, 
the user need never see the YURL itself)

2. it can be left as a plain text YURL (for compatibility)

3. the sender's system could dynamically produce a new YURL which 
proxies the original YURL (if you want to maintain control and don't 
want it divulged)

4. the sender's system could dynamically produce a new YURL which merely 
displays the original YURL when accessed (I'm not sure if this is any 
better than #3 -- I was trying to think of a way to handle unencrypted 
e-mails more securely)

I believe this somewhat fulfills Jed's dream of a standard network 
capabilities and transferring capabilities via e-mail.

Sandro