Re: [OAUTH-WG] draft-ietf-tls-oob-pubkey: My summary

["Manger, James H" <[e-mail]>]

> III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case)
> 
> client_hello,
> cert-receive=(X.509, Raw) // (1)
> cert-send=(Raw)             -> // (2)
> 
>                          <-  server_hello,
>                              cert-info=(X.509),// (3)
>                              certificate, // (4)
>                              certificate_request, // (5)
>                              cert-receive=(Raw) // (6)
>                              server_key_exchange,
>                              server_hello_done
> 
> cert-info=(Raw), // (7)
> certificate, // (8)
> client_key_exchange,
> change_cipher_spec,
> finished                  ->
> 
>                          <- change_cipher_spec,
>                             finished
> 
> Application Data        <------->     Application Data
> 
> Legend:
> 
> (1) Client accepts to receive X.509 certs and raw public keys, in this
> order of preference. (Could also be X.509 only in this example)
> (2) The client does have a raw public key for client authentication.
> (3) The server decides to sends his X.509 cert and indicates this in
> the cert-info field.
> (4) The certificate payload contains the X.509 cert.
> (5) The server wants to use client authentication and sends a cert-
> request.
> (6) The certificate request asks for a certificate of type 'raw'
> (knowing that the client supports it from (2)).
> (7) The client indicates that the certificate payload contains a raw
> public key.
> (8) Here is the payload of the certificate itself.


So the OAuth client completes a TLS handshake with a protected resource using a raw key, but the protected resource doesn't get any authorization for that raw key until it sees an access_token which appear where? In an HTTP header somewhere in the App Data some time after the TLS handshake finishes?

--
James Manger