Re: [OAUTH-WG] Holder-of-the-Key for OAuth

inline

On 2012-07-10, at 8:44 PM, Manger, James H wrote:

> William Mills wrote:
> > The server would need to issue a key pair and not just the private key.  Are you saying the private key is for the certificate, and that certificate is part of the access_token?
>  
> Yes. The AS issues temporary credentials for the client app to use. In this case the credentials are a public/private key pair and associated certificate to be used in TLS. The cert (which includes the public key and any info the AS wants) is returned in the “access_token” field. The private key is returned in a separate field.
>  
>  
> John Bradley wrote:
> > I suspect that we will need two OAuth bindings. One for TLS and one for signed message.
>  
> I agree. For instance, set “token_type”:”tls_client_cert” when the client has to use TLS; set “token_type”:”cms” when the client has to digitally sign messages using Crypto Message Syntax (CMS); ….
>  
Perhaps JWT/JOSE rather than CMS:)

Though there will need to be discussions about what part of the message needs to be signed.

>  
> > We should be supporting both the client providing the key pair and a server generated pair.
>  
> Ok. Do you expect a client app to use a separate key pair for each authorization? Or do you expect a client app to have one key pair for all actions (on behalf of all users) and use the access_token to distinguish the authorization in each request? Or something in between?
>  
Using a separate key pair per authorization is not required for asymmetric keys.
The idea is that the presenter of the token needs to prove that they know the proof key.

The only reason to change the key would be privacy, to prevent correlation.

If we look at how openID Connect used id_tokens a ephemeral key generated by the user agent on a per client basis may be useful.

The Client and the token issuer should sort out the proof mechanism and key rotation.

The protected resource should only care about the proof based on the token it receives.  

I think part of this is a JWT/JOSE issue and part of this ia a OAuth binding or bindings issue.

John B.

> --
> James Manger
>  
> From: "Manger, James H" <James.H.Manger@team.telstra.com>
> To: Hannes Tschofenig <hannes.tschofenig@gmx.net>; OAuth WG <oauth@ietf.org> 
> Sent: Monday, July 9, 2012 8:54 PM
> Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth
> 
> Hannes,
> 
> > today I submitted a short document that illustrates the concept of
> > holder-of-the-key for OAuth.
> > Here is the document:
> > https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk 
> 
> 
> A different approach would be for the service to issue a private asymmetric key to the client app, along with a certificate, in the access token response. This is a slightly better match to the OAuth2 model of the authorization service issuing temporary credentials for accessing resources on a user’s behalf.
> 
> When the token_type is "tls_client_cert" (probably a better label than "hotk"), the client can access protected resources using TLS with client authentication; using the key from the "private_key" field. The "access_token" field holds a base64url-encoded certificate to include in the TLS handshake.
> 
> An example access token response could be:
> 
>   HTTP/1.1 200 OK
>   Content-Type: application/json;charset=UTF-8
>   Cache-Control: no-store
>   Pragma: no-cache
> 
>   {
>     "token_type":"tls_client_cert",
>     "access_token":"MIIGcDCCBdmgAwIBAgIKE…",
>     "private_key":{
>       "alg":"RSA", "mod":"Ovx7…", "p":"7dE…", "q":"fJ3…", …
>     },
>     "expires_in":3600,
>     "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
>   }
> 
> 
> The suggestion above passes the "access_token" to the protected resource in the TLS protocol in the form of a certificate.
> draft-tschofenig-oauth-hotk says the client "presents the access token to the resource server", but it wasn't clear to me how it was done. Were you expecting the client to use the BEARER HTTP auth scheme inside the client-authenticated TLS connection?
> 
> --
> 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