1. OAuth WG Conference Call, 11th Jan. 2013
OAuth 2.0 Security
OAuth WG Conference Call, 11th Jan. 2013

2. Crypto-Agility [C->RS: Discovery]
C->AS: [algorithm list]**, id(RS), id(client), scope
C<-AS: algorithm*, key, access token
C->RS: algorithm, HMAC/signature, access token***
C<-RS: OK.
*Assumption: AS knows what algorithms are supported by the RS. AS selects appropriate algorithm from the client-provided list.
**: Algorithm list & token types could be conveyed implicitly via the client id. Client registers the data during the registration phase.
***: Alternatively an error message is returned if no common algorithms are supported.

3. Confirm Cryptographic Algorithm Selection
Client supported list of algorithms cannot be modified since it is sent over a TLS protected channel.

4. Uniquely Named Keys
Key used for client authentication is named via Client_id
Key used to protect the access token is named kid (if the JOSE work is used).
Session key used for client<->RS interaction could be named via id (as in MAC draft).
Should a session key also be used for a subsequent exchange of data between the client and the resource server?

5. Authorization Restriction
Information needed by client:
Lifetime of the session key + Key identifier
Authorization Scope
Resource Server the access token can be used
(Any information related to delegation, or post-dated access tokens.)

6. Bind Key to its Context
Session key to be used for client-to-RS interaction
Lifetime of session key.
Symmetric key: lifetime of access token
Asymmetric key: longer lifetime
Who has access to the session key? Depends on the type:
Symmetric: AS, client instance, RS
Asymmetric: privacy key known to the client instance only

7. Prevent the Domino Effect
What happens when a client gets compromised?
Rouge client must not get access to resources of resource owners who have been interacted with that client.
What happens when a resource server gets compromised?
Rouge RS must not be able to impersonate clients to other RSs

8. Strong, fresh session keys
Randomly generated with sufficient entropy
Client id:
client id is not visible to RS
Joint key control (client & AS) for symmetric keys?
Scope
Should a different session key be used when the scope changes?
Lifetime of C<->RS session key :
For symmetric keys: lifetime of the session key is bound to the access token lifetime.

9. Replay Detection Mechanism
Based on timestamp with optional seq-number

10. Authenticate All Parties
AS authenticated by the client
Client authentication to the AS (mandatory?)
Client authentication to the RS via keyed message digest/signature
RS authentication to the client?

11. Authorization Resource Owner is authorized by the AS.
Client is authorized by the AS via client authentication (mandatory?)
RS authorizes client based on access token in combination with proof of possession of key.
AS authorizes RS via the encrypted session key.

12. Keying Material Confidentiality and Integrity
Client obtains session key via TLS protected channel.
If refresh token leaks then it can be used to obtain access token + new session key. The refresh token behaves like a bearer token. A problem?
Without channel binding the TLS tunnel may terminate before the AS
RS obtains session key via encrypted access token (in case of symmetric keys)
(optionally: RS obtains session key from AS)

13. Client Identity Confidentiality
A Client has identity confidentiality when any party other than the Resource Server and the Authorization Server cannot sufficiently identify the Client within the anonymity set.
Client to AS exchange is confidentiality protected.
Client id is not exposed to RS.

14. Resource Owner Identity Confidentiality
Only the Authorization Server gets to know the identity of the resource owner
Unless a JWT carries a "sub" (Subject) Claim

15. Collusion
The Authorization Server can be prevented from knowing which Resource Servers a Resource Owner interacts with.
Consequence:
The AS is unable to populate the audience field in a JWT.
The AS cannot encrypt a session key for usage with a specific RS.
Best supported with asymmetric cryptography
Is this a desirable feature for an initial version?