> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
