We should be supporting both the client providing the key pair and a server generated pair.
In higher security the private key may be stored in hardware. There are more possible attacks if the key is sent to the client. John B. Sent from my iPhone On 2012-07-10, at 12:53 PM, William Mills <wmills_92...@yahoo.com> 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? > > > From: "Manger, James H" <james.h.man...@team.telstra.com> > To: Hannes Tschofenig <hannes.tschofe...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
