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
--