Subject: [OAUTH-WG] Core Token Classes

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 15:34:16 -0700

The proposed authentication scheme switches to use token classes instead of signature methods. Instead of the server supporting certain kinds of signature methods, the server supports certain kind of token classes. When clients obtain tokens from the server, they are told what the class of the token is, and what realm it is for (we still need to work out realm scoping details).

Discovery (of some sort) will connect the two parts and tell the client how to get a token of a certain class from the server.

This brings us to the core token classes to be included in the Token scheme specification. Others will require an RFC (or Open Standard) and a registration.

I am proposing the following core set:

-- hmac-sha-1

Token is issued with a symmetric secret appropriate for use with the HMAC-SHA-1 algorithm over a normalized representation of the HTTP request.

-- hmac-sha-256

Token is issued with a symmetric secret appropriate for use with the HMAC-SHA-256 algorithm over a normalized representation of the HTTP request.

-- rsassa-pkcs1-v1.5-sha-256

Token is associated with PK appropriate for use with the RSASSA-PKCS1-v1.5 method using the SHA-256 hash algorithm over a normalized representation of the HTTP request. The client will have access to the private key while the server will have access to the public key.

-- basic-hmac-sha-1

A special case token which allows using Basic Authentication credentials (username and password) as an hmac-sha-1 class token. The password will be used as the symmetric shared secret. This token class is assigned a special name to reflect the source of the credentials and make it trivial to deploy as a direct replacement for Basic Auth.

-- bearer-opaque

A secret-less token class using an opaque string. The 'opaque' label is used to indicate that this is a server-issued token with a structure unknown to the client. I expect other bearer token classes to be defined later to allow the client or other entities to self-issue a token (for example, a SWT token can be called bearer-swt).

Comments?

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Dec 2009 17:26:21 -0700

Please ignore basic-hmac-sha-1. It was poorly conceived. I'll come back with something better.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Friday, December 04, 2009 2:34 PM
> To: OAuth WG ([email-masked])
> Subject: [OAUTH-WG] Core Token Classes
> 
> The proposed authentication scheme switches to use token classes instead
> of signature methods. Instead of the server supporting certain kinds of
> signature methods, the server supports certain kind of token classes. When
> clients obtain tokens from the server, they are told what the class of the
> token is, and what realm it is for (we still need to work out realm scoping
> details).
> 
> Discovery (of some sort) will connect the two parts and tell the client how to
> get a token of a certain class from the server.
> 
> This brings us to the core token classes to be included in the Token scheme
> specification. Others will require an RFC (or Open Standard) and a
> registration.
> 
> Token is issued with a symmetric secret appropriate for use with the HMAC-
> SHA-1 algorithm over a normalized representation of the HTTP request.
> 
> -- hmac-sha-256
> 
> Token is issued with a symmetric secret appropriate for use with the HMAC-
> SHA-256 algorithm over a normalized representation of the HTTP request.
> 
> Token is associated with PK appropriate for use with the RSASSA-PKCS1-v1.5
> method using the SHA-256 hash algorithm over a normalized representation
> of the HTTP request. The client will have access to the private key while the
> server will have access to the public key.
> 
> -- basic-hmac-sha-1
> 
> A special case token which allows using Basic Authentication credentials
> (username and password) as an hmac-sha-1 class token. The password will
> be used as the symmetric shared secret. This token class is assigned a special
> name to reflect the source of the credentials and make it trivial to deploy as a
> direct replacement for Basic Auth.
> 
> -- bearer-opaque
> 
> A secret-less token class using an opaque string. The 'opaque' label is used to
> indicate that this is a server-issued token with a structure unknown to the
> client. I expect other bearer token classes to be defined later to allow the
> client or other entities to self-issue a token (for example, a SWT token can be
> called bearer-swt).
> 
> Comments?
> 
> EHL
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth