Re: auth handshake and rendevouz objects

[Tom Hart]

Marcus Brinkmann wrote:
> On Tue, Nov 05, 2002 at 05:32:34PM +0100, Niels Möller wrote:
> > Marcus Brinkmann <address@hidden> writes:
> > > Well, one question is surely resource allocation.  I think A should provide
> > > the resource to S that contains the note that B should get a reference to
> > > the handle.
> > Hmm. Sounds a little hairy. I think one would really want the
> > following protocol:
> >
> > 1. A->B:    I'd like to give you the handle (S,x).
> > 2.  B->S:   Gimme handle x. A said I could have it.
> > 3.   S->A:  Do you really want to give x to B?
> > 4.   A->S:  Sure.
> > 5.  S->B:   Ok, here's the handle.
> > 6. B->A:    Thanks, I've got it now.
> >
> > Except that there's one S->A message, 3, and you say you'd like to
> > avoid that. I'd be a little surprised if one can come up with an
> > alternative that avoids both the callback from S to A, and state in S.

I'm sure I'm being stupid, here, but is there any way that A can return 
a digitally-signed token to B, so that the protocol becomes:

1. A->B:     I'd like to give you the handle (S,x); here's an
                authorization token.
2. B->S:     Gimme handle x. Here's a digitally-signed token from A.
3. S checks the digital signature that B passed it, and confirms that
it came from A.
4. S->B:     Ok, here's the handle.
5. B->A:     Thanks, I've got it now.

This would, of course, require the servers to have a public-key database 
in local storage, to avoid an RPC call to a public-key server.

Again, I'm sure I'm being stupid here, but I wanted to throw the idea 
out there, just in case.

--
    _______________________________________________
   /                                               |
  /  Tom Hart                                      |
 |   address@hidden                          |
  \  "rmTFM - Build consistent interfaces."        |
   \_______________________________________________|