At the moment there is no hok proof in the token itself. It seems to be bound in tls.
The spec isn't clear yet that a token is passed in 3.2. But I assumed that is what Hannes intended. Still since there is no comment about passing the token I guessed it would essentially be a bearer token backed by a client authenticated tls. Phil On 2012-07-13, at 6:32, John Bradley <[email protected]> wrote: > I am not saying it is unusual in a bad way. > > Some people think of TLS client auth happening at the TLS layer. That is > common in server to server connections. > > Decisions based on the client cert can happen at the app layer, as they do in > SAML HoK. > > I think people have less experience with doing that though. > > John B. > On 2012-07-13, at 8:35 AM, Hannes Tschofenig wrote: > >> Hi John, >> >> authorization decisions are not made by the TLS library - they are made by >> the application. >> >> For example, in the HTTPS case the authorization decision that is made by >> the client is to compare the content of the cert with the domain part of the >> HTTP URI. Similar authorization decisions are being made by many >> applications using HTTP, see http://tools.ietf.org/html/rfc6125. >> >> So, there is nothing unusual here. >> >> >> Ciao >> Hannes >> >> >> On Jul 13, 2012, at 3:13 PM, John Bradley wrote: >> >>> It sucks for TLS hinting:) >>> >>> In principal the client needs to know what keypair to use for the TLS >>> session before it is initiated. >>> >>> The protected resource establishes the session with client auth accepting >>> any client key. >>> >>> The protected resource compares the client key passed in from TLS with the >>> one in the token as part of token validation, and accepts or rejects the >>> token. >>> >>> It is different from "normal" TLS client auth in that it is not the TLS >>> layer making the access decision. >>> >>> John B. >>> On 2012-07-12, at 11:40 AM, Manger, James H wrote: >>> >>>>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
