[cap-talk] A palatable solution?
smagi at naasking.homeip.net
Wed Nov 30 16:12:28 EST 2005
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
> 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
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
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.
More information about the cap-talk