On Sat, Dec 06, 2014 at 02:19:34PM -0500, Derek Atkins wrote: > The OAUTH Working Group is already (and has been for a while!) looking > into "holder of key" protocols to improve upon Bearer Tokens. > > I would suggest that this work happen there instead of creating a whole > new group for it. That's very interesting. Key confirmation protocols will tend to all look... roughly similar: a synchronous exchange of "messages" (with cryptographic elements, of course) between a "client" and a "server" (with perhaps infrastructure message in the background) until one, the other, or both peers are authenticated to the other, or the authentication fails. If you can have keys at all, you can also have session keys, though for HTTP.. until we get something better than web cookies for session continuation, having session keys is hardly critical. Anyways, there's a reason I mention this: we already have several protocols that look like this, so new not-just-bearer-anymore bearer token extensions have literature to look at. A brief list of such protocols that might be useful for lessons to good, bad, and ugly: TLS, SASL (and various mechanisms), GSS-API (and various mechanisms), Kerberos V5, IKEv1 and IKEv2, ... Of those, these tend to have actual APIs in the wild that might be useful too: TLS (ad-hoc APIs), SASL (ad-hoc APIs), GSS (standard APIs), Kerberos (ad-hoc APIs), IKEv* (PF_KEY -- a standardish socket API). I'm not sure which lessons OAuth and others going down this path should take. I'll try to think of some so as to save the authors the time of having to digest all this material. I suggest others also do this. Nico --