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