1. OAuth Design Team Call
11th February 2013

2. Security Design Requirements
Focus on symmetric key cryptography
Use MAC Token spec as a starting point
Lifetime of session key = Lifetime of access token
Unless the sequence number space wraps
Replay protection: Timestamp + [sequence number]
Support for TLS channel bindings
Integrity protection for data exchange between the client and the resource server, and vice versa.
“Flexibility” regarding keyed message digest computation
Crypto-Agility: Algorithm indication from Authorization Server to the Client.

3. Remaining Decisions Key distribution:
Three mechanisms presented. Which one should focus on?
Key naming: New key identifier (kid) parameter?
Allow Client to indicate to which RS is wants to talk to?

4. DKIM Signature Recap
body-hash: is the output from hashing the body, using hash-alg.
data-hash: is the output from using the hash-alg algorithm, to hash the header including the DKIM-Signature header, and the body hash.
h-headers: is the list of headers to be signed, as specified in the "h" parameter.
h= Signed header fields
Example: h=Received : From : To : Subject : Date : Message-ID;
Alternative: IANA registration for example

5. Key Distribution Three techniques: Key point: What is MTI?
Key Transport
“Key Retrieval”
Key Agreement
Key point: What is MTI?

6. How RS obtains the Session Key? Option#1: Key Transport

7. How RS obtains the Session Key? Option#2: “Key Retrieval”
Key Request

8. How RS obtains the Session Key? Option#3: Key Agreement
Key Request