Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)

[Chuck Mortimore <[e-mail]>]

Yes - sounds about what I'm looking at

For the scenario, we'd have a client talking to our authorization server
that is also paired with it's own cloud backend.   The cloud would have a
certificate pre-reigstered with our authorization server, and the client
would dynamically generate it's own public/private key.    Both would be
able to prove possession using their own keys without sharing.    So to
answer mike's data structure question, it would looks something like this

1) Client requests id token and in the authorization request it passes in
its newly minted public key ( or perhaps a thumbprint but not covering that
here)

2) Authorization server authorizes, and mints new id token as jwk set
containing both the dynamically generated client key and also the cert for
its server:

{
     "iss": "https://login.salesforce.com",
     "sub": "
https://login.salesforce.com/id/00D30000001bZxaEAE/00530000009UVC0AAO"
     "aud":
"3MVG99OxTyEMCQ3gXuX31lysX3RQP4.Vj3EVzlMsVbxFvUe7VjZ0WcjWvGlAU7BPJFZBSyBGPiGyHhojZ2BE3",
     "exp": 1397352138,
     "iat": 1397352018,
     "cnf":
  {
"keys":[
{
"kty": "RSA",
"n": "AKPBc9I142dEc-Srdk5sz9MVaJH_k....",
"e": "AQAB",
"alg": "RS256"
},
{
"x5c":["MIIDQjCCAi...."]
}
]
}
}


The id token can then be presented to something like our oauth token
endpoint as an assertion by either the client application such as a mobile
app, or the server infrastructure it's paired with.   The client's key is
client specific.   The server's key is global for the application.  No need
to share between them, and the capabilities of the grant could vary.

Proof would simply be constructing a JWT that signs the id token with the
required key:
outerheader.base64url(innerheader.body.innersignature).outersignature

-cmort



On Sun, Apr 13, 2014 at 8:34 AM, John Bradley <[e-mail]> wrote:

> I think Chuck is largely referring to the scenario that Connect supports
> for issuing id_tokens for 3rd parties but where the 3rd party also wants a
> access token to access the API.
>
> This is similar to the Google Play / NAAPS use case, but with access
> tokens using PoP back to the 1st party RS.
>
> Now using bearer tokens the native app can just pass the AT to a backend
> server hand have it make calls to the RS.  The AS is no wiser to the
> activity.
> However PoP is designed to stop this sort of thing.
>
> As I think Chuck intimated, you could share the private key between the
> app and the backend, but giving your servers private key to a app seems
> like a good way to loose it.
>
> The alternatives are:
> 1 share keys (bad)
> 2 put multiple proof keys in the token (needs the keys to be pre
> registered and ads complexity for symmetric keys.
> 3 Give client an assertion that can be used by the related backend to get
> it's own AT, allowing the clients to have different client_id and proof
> keys. (builds on Connect id_token used in jwt assertion flow)
>
> John B.
>
> On Apr 13, 2014, at 1:17 AM, Mike Jones <[e-mail]>
> wrote:
>
> Can you sketch out what data structures you'd ideally use for your
> scenario and what the elements mean?
>
> *From:* Chuck Mortimore [mailto:[e-mail]<[e-mail]>
> ]
> *Sent:* Saturday, April 12, 2014 8:39 PM
> *To:* Mike Jones
> *Cc:* [e-mail]
> *Subject:* Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web
> Tokens (JWTs)
>
> Not sure it it's common yet.   The scenario I'm exploring is a client that
> is paired with a server.     For example, a mobile app that's an OpenID
> Connect client that is sharing it's ID Token with the server.   Both the
> client and server want to be able to prove possession without sharing a
> private key.
>
> -cmort
>
>
> On Sat, Apr 12, 2014 at 8:32 PM, Mike Jones <[e-mail]>
> wrote:
> Is having multiple confirmation keys a common case?  I'd rather we "make
> simple things simple" than build the most general solution possible.  If an
> application really needs multiple confirmation keys, it can always defined
> a "jwks" element and the handling rules for it, and go for it...
>
>                                                             -- Mike
>
> *From:* Chuck Mortimore [mailto:[e-mail]]
> *Sent:* Saturday, April 12, 2014 6:12 PM
> *To:* Mike Jones
>
> *Cc:* [e-mail]
> *Subject:* Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web
> Tokens (JWTs)
>
> Good start here Mike!
>
> One quick question - I see the "cnf" member is defined as a JWK.  Why not
> a JWK Set?    I could see use-cases for binding in multiple keys.
>
> -cmort
>
>
>
>
> On Tue, Apr 1, 2014 at 8:36 PM, Mike Jones <[e-mail]>
> wrote:
> I've written a concise Internet-Draft on proof-of-possession for JWTs with
> John Bradley and Hannes Tschofenig.  Quoting from the abstract:
>
> *This specification defines how to express a declaration in a JSON Web
> Token (JWT) that the presenter of the JWT possesses a particular key and
> that the recipient can cryptographically confirm proof-of-possession of the
> key by the presenter. This property is also sometimes described as the
> presenter being a holder-of-key.*
>
> This specification intentionally does not specify the means of
> communicating the proof-of-possession JWT, nor the messages used to
> exercise the proof key, as these are necessarily application-specific.
> Rather, this specification defines a proof-of-possession JWT data structure
> to be used by other specifications that do define those things.
>
> The specification is available at:
>
> ·
> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-00
>
> An HTML formatted version is available at:
>
> ·
> http://self-issued.info/docs/draft-jones-oauth-proof-of-possession-00.html
>
>                                                             -- Mike
>
> P.S.  This note was also posted at http://self-issued.info/?p=1210 and as
> @selfissued.
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>