I think having the proof in the token works for SAML and JWT. I would like to also allow for an opaque token that the RS may deference to get the key.
John B. On 2012-07-13, at 10:40 AM, Phil Hunt wrote: > 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
