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

From: Mike Jones <[email-masked]>
Date: Wed, 2 Apr 2014 03:36:53 +0000

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.

---

From: "Manger, James" <[email-masked]>
Date: Wed, 2 Apr 2014 16:50:22 +1100

> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-00

A new registry for "cnf" members is a bit strange. A JWT Claim Set has so far been a flat structure, with metadata such expiry date "exp" alongside claims such as "given_name". This spec starts introducing structure by wrapping members in a "cnf" (confirmation) object. It is not clear to me which new things would go in "cnf" versus going in to the top-level of the JWT claim set. Both locations have a "MUST ignore" policy for unrecognized members.

   "(In some applications, the subject identifier will be relative
   to the issuer identified by the "iss" (issuer) claim.)"

This isn’t very helpful as it gives no hint about when this is or isn’t the case. I guess this is just rewording a flaw from JWT.

Could the JWE example please include a "kid"? The recipient needs to know which key to use to decrypt the message. JWS says we SHOULD do this [JWS §6 2nd paragraph]. [P.S. Weren’t we going to include "kid" is almost all the examples in JWE?]

You may as well drop the "cty":"jwk+json" member as this is implied by the JOSE message being the value of a "jwk" member.

OpenID Connect has already defined a "sub_jwk" field that performs a similar role to "cnf":{"jwk"}.
[http://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedResponse]

Perhaps the biggest security consideration is missing: "cnf" may be ignored. A recipient that doesn't understanding "cnf" is likely to accept a JWT as a bearer token without doing any proof-of-possession.

--
James Manger

---

From: John Bradley <[email-masked]>
Date: Wed, 2 Apr 2014 09:44:34 -0400

Thanks for the feedback.

inline

> A new registry for "cnf" members is a bit strange. A JWT Claim Set has so far been a flat structure, with metadata such expiry date "exp" alongside claims such as "given_name". This spec starts int…

This is the first draft so this needs to be fleshed out.  The idea is to have a single object that contains what in SAML would be the subject confirmation information.   I expect hat the protocols using this are going to determine what claims need to go in cnf.   

As an example for bearer tokens there might be an expirey time for presentment that is separate from the tokens lifetime as represented by "exp" at the top level.
This may not be a great example as people in general don't understand the difference between the two exp in SAML:)   

But in general cnf contains claims that are required to confirm that the presenter is the subject/issuer or a designated agent.

> This isn’t very helpful as it gives no hint about when this is or isn’t the case. I guess this is just rewording a flaw from JWT.

This is one thing we have been wrangling over the wording of.

In the simple case where there is a "sub" then the key represents the proof key of the presenter or a authorized agent on there behalf.

There are some slippery bits even in that as it is the recipient that is trusting the issuer to put in the correct cnf information. Especially in cases where there may be multiple hops the key may be that of a RS that the user has no direct trust relationship with.

In the case where there is no subject, I tend to think of the JWT as having a implicit subject that is the issuer as that is really the only thing the claims could be about in the absence of a explicit subject.
A JWT without a subject could have a claim about a user that is logged into me but the me is the issuer.

So as in the case of there being no explicit subject the cnf is of the iss or a agent it has designated.

In principal if a intermediary receives the token and sends it to a STS like service the resulting JWT would then have the STS as the iss and the original iss as the sub.  Though that is outside of this spec.

Trying to come up with a simple explanation without dragging a bunch of other stuff in to the spec is not easy.

Perhaps something more like the cnf must evaluate to true for the presenter of the JWT otherwise the token is not being presented by a party authorized by the issuer, given that the recipient's primary trust relationship is with the issuer.

Trying to say who the presenter is may just be too confusing at this level.

Thoughts and wording input appreciated.

> Could the JWE example please include a "kid"? The recipient needs to know which key to use to decrypt the message. JWS says we SHOULD do this [JWS §6 2nd paragraph]. [P.S. Weren’t we going to inclu…

Yes it should include a "kid"
> You may as well drop the "cty":"jwk+json" member as this is implied by the JOSE message being the value of a "jwk" member.
It may be useful to libraries processing the JWE.

> [http://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedResponse]

As you have pointed out connect self Issued needs an errata to address a problem anyway.

They are similar though the self issued case is more like a JWT that would be used as a proof mechanism rather than as a pop token itself.

Perhaps there is a case where the iss is using it's signing key for signing the token and via tls channel binding for presentment as an example. 

The connect case doesn't require a presentment proof so is a bit different.    

I take your point and will think about it a bit more.

> Perhaps the biggest security consideration is missing: "cnf" may be ignored. A recipient that doesn't understanding "cnf" is likely to accept a JWT as a bearer token without doing any proof-of-poss…

I think the protocol using the JWT would likely be where the requirement would be enforced along with the presentment mechanism.

John B.

> --
> James Manger
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Wed, 2 Apr 2014 17:47:13 +0000

Thanks for the comments, James.  Comments inline marked with "Mike>".

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, April 02, 2014 6:45 AM
To: Manger, James
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)

Thanks for the feedback.

inline

Mike>  Another possible example is that a "kid" (Key ID) value might be used in the "cnf" (confirmation) object, rather than including the key directly.  This actually matches the SAML construct in which the SubjectConfirmation element contains a KeyInfo element that contains a KeyName element, rather than the key value.  In this case, you need the "kid" to be within the "cnf" object to distinguish it from the "kid" referring to the signing key.

> This isn't very helpful as it gives no hint about when this is or isn't the case. I guess this is just rewording a flaw from JWT.

Mike> I agree with John that it's up to applications using this spec to say who the presenter is - just like it's up to applications using JWT to specify what the values of the "iss" and "sub" fields are for that application, and which of them are required.  That said, suggestions on how to make this clearer would of course be welcomed.

> Could the JWE example please include a "kid"? The recipient needs to know which key to use to decrypt the message. JWS says we SHOULD do this [JWS §6 2nd paragraph]. [P.S. Weren't we going to include "kid" is almost all the examples in JWE?]

Mike> You mean adding a "kid" to the JWE Header?  Yes, I can do that in the next revision.  (No "kid" is needed in the proof-of-possession key because it's passed by value, so there's no ambiguity what the key is.)

Mike> I agree with James that, in context, it's already known that the content type of the JWE Plaintext is a JWK, and so this can be dropped (which is allowed in the JWK spec).

Mike>  I agree with John here.  I can easily imagine use cases in which it's up to the recipient how often to check possession.  For instance, it might decide to incur the additional overhead only if possession hadn't been checked for longer than a certain time threshold.  We don't want to preclude those use cases.

                                                                -- Mike

John B.

> [email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: Chuck Mortimore <[email-masked]>
Date: Sat, 12 Apr 2014 18:12:06 -0700

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 <[email-masked]>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.
>
>
>
> ·
> ·
> http://self-issued.info/docs/draft-jones-oauth-proof-of-possession-00.html
>
>
>
>                                                             -- Mike
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Sun, 13 Apr 2014 03:32:52 +0000

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:[email-masked]]
Sent: Saturday, April 12, 2014 6:12 PM
To: Mike Jones
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
I've written a concise Internet-Draft on proof-of-possession for JWTs with John Bradley and Hannes Tschofenig.  Quoting from the abstract:

                                                            -- Mike

---

From: Chuck Mortimore <[email-masked]>
Date: Sat, 12 Apr 2014 20:39:25 -0700

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 <[email-masked]>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:[email-masked]]
> *Sent:* Saturday, April 12, 2014 6:12 PM
> *To:* Mike Jones
>
> *Cc:* [email-masked]
> *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
>
>
>
>
>
>
>
> I've written a concise Internet-Draft on proof-of-possession for JWTs with
> John Bradley and Hannes Tschofenig.  Quoting from the abstract:
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Sun, 13 Apr 2014 04:17:29 +0000

Can you sketch out what data structures you'd ideally use for your scenario and what the elements mean?

From: Chuck Mortimore [mailto:[email-masked]]
Sent: Saturday, April 12, 2014 8:39 PM
To: Mike Jones
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, April 12, 2014 6:12 PM
To: Mike Jones

Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)

Good start here Mike!

-cmort

                                                            -- Mike

---

From: John Bradley <[email-masked]>
Date: Sun, 13 Apr 2014 12:16:20 -0300

The client should request a second token for the server rather than try and overload both into the same token.

Or based on the first token the server should use that to exchange it for one that has it's proof key.

In general you want the requester to be able to prove that it has the proof key, or the private key used to decrypt the proof key to get the full benefit.

I can see how having multiple entities able to present the token along with multiple audiences in the token may seem like a simplification for issuing tokens, but I would rather keep the basic model simple and go hop by hop.   I understand that may require a more REST STS like capability than exists in the current token endpoint.

On Apr 13, 2014, at 12:39 AM, Chuck Mortimore <[email-masked]> wrote:

> On Sat, Apr 12, 2014 at 8:32 PM, Mike Jones <[email-masked]> 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
> 
>  
> 
> On Tue, Apr 1, 2014 at 8:36 PM, Mike Jones <[email-masked]> wrote:
> 
> I’ve written a concise Internet-Draft on proof-of-possession for JWTs with John Bradley and Hannes Tschofenig.  Quoting from the abstract:
> 
>  
> 
> ·        http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-00
> 
>  
> 
> ·        http://self-issued.info/docs/draft-jones-oauth-proof-of-possession-00.html
> 
>  
> 
>                                                             -- Mike
> 
>  
>

---

From: John Bradley <[email-masked]>
Date: Sun, 13 Apr 2014 12:34:04 -0300

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 <[email-masked]> wrote:

> Can you sketch out what data structures you’d ideally use for your scenario and what the elements mean?
>

---

From: Chuck Mortimore <[email-masked]>
Date: Sun, 13 Apr 2014 09:31:41 -0700

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 <[email-masked]> 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.
> 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.
>
> *From:* Chuck Mortimore [mailto:[email-masked]<[email-masked]>
> ]
> *Sent:* Saturday, April 12, 2014 8:39 PM
> *To:* Mike Jones
> *Cc:* [email-masked]

---

From: Chuck Mortimore <[email-masked]>
Date: Sun, 13 Apr 2014 11:05:40 -0700

Was also trying to work through what this would look like with thumbnails.
   Does this sounds right?

1) Client generates a private / public key

2) Client calculates a public key thumbprint like this:
http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00

For example for this key

{"e":"AQAB","kty":"RSA","n":"0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2
    aiAFbWhM78LhWx4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCi
    FV4n3oknjhMstn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65Y
    GjQR0_FDW2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n
    91CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_x
    BniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw"}

You'd arrive  at: NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs

3) Client passes the thumbprint in an oauth authorization request as a
parameter "jkt=NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs"

4) Authorization server constructs an id_token like this:

{

    "sub": "

    "aud":

    "exp": 1397352138,

    "iat": 1397352018,

    "nbf": 1397352018,

    "cnf":{

    "jwk":{

                          "jkt":
"NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs"

}

 }

}

5) This ID Token can then be passed by the client or a delegate with the
key to the token endpoint via JWT bearer flow and prove possession by
constructing a JWT that looks like this:

{"alg":"RS256"}

.

{

    "jwk":{

"kty": "RSA",

"n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2
    aiAFbWhM78LhWx4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCi
    FV4n3oknjhMstn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65Y
    GjQR0_FDW2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n
    91CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_x
    BniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",

"e": "AQAB"

    }

    "pop": "base64url encoded id token",

}

.

signture with private key

When this is posted as a JWT bearer assertion, the token endpoint

a) verifies that the outer signature matches the public key, b) that the
public key matches the thumbprint signed into the inner id token, and c)
that the signature on the id token is valid.   It can than act as then
issue a token response for the sub of the inner id token

Look correct?

-cmort

On Sun, Apr 13, 2014 at 9:31 AM, Chuck Mortimore
<[email-masked]>wrote:

>> 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
>>
>>

---

From: John Bradley <[email-masked]>
Date: Sun, 13 Apr 2014 16:57:50 -0300

That is one way it might be done.

Sending the thumbprint in the authorization request is similar to sec 2.2 https://tools.ietf.org/html/draft-sakimura-oauth-tcse-02

I have always thought of that spec as wanting to be a a proof of possession for code.

So in the case where the AS and the token endpoint are in the same security domain this is really just a code flow with the thumbprint in "code_challenge" or "jkt"
Then uses the assertion flow to authenticate as you describe.

For native apps this avoids per instance registration and gets you almost all the benefits of a private client.

Nothing stops you from making code a JWT and passing the thumbprint to the Token endpoint statelesly.  
The token endpoint can then use the same pattern for generating the refresh token and on down to the access token.

We want to separate the logical parts to document:
1  the format of the JWT itself
2 Getting a pop token and key establishment
3 using a PoP token at a RS
4 PoP presentment at the token endpoint for code and refresh. (I think it is important, but some think it is low priority,  In OAuth people have mostly been thinking about PoP at the RS)

As you point out with the JWT assertion flow PoP is posable for clients that are otherwise public with a bit of profiling.

The format you propose is similar to http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00  If you mix in PoP.  

Perhaps it is just a "urn:ietf:params:oauth:grant-type:jwt-pop" grant_type where code is used as the pop value in your example.  
If we were talking about Connect then yes we might use the id_token returned, but for the id_token with the client as the aud I hope we can eventually have the user agent provide a proof key once we have web crypto available.  So overloading the id_token may not be as simple as just treating the value of code as an assertion that can be a JWT/SAML/or reference.

John B.

On Apr 13, 2014, at 3:05 PM, Chuck Mortimore <[email-masked]> wrote

> Was also trying to work through what this would look like with thumbnails.    Does this sounds right?
> 
> 
> 2) Client calculates a public key thumbprint like this:  http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00
> 
> For example for this key
> 
>  You’d arrive  at: NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
> 
> 3)  Client passes the thumbprint in an oauth authorization request as a parameter “jkt=NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs”
> 
>      "sub": "https://login.salesforce.com/id/00D30000001bZxaEAE/00530000009UVC0AAO"
>      "aud": "3MVG99OxTyEMCQ3gXuX31lysX3RQP4.Vj3EVzlMsVbxFvUe7VjZ0WcjWvGlAU7BPJFZBSyBGPiGyHhojZ2BE3",
>      "exp": 1397352138,
>      "iat": 1397352018,
>      "nbf": 1397352018,
>      "cnf":{
> 	    "jwk":{
>                            "jkt": “NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs”
>  }
> 	 }
> } 
> 
> 
> 5) This ID Token can then be passed by the client or a delegate with the key to the token endpoint via JWT bearer flow and prove possession by constructing a JWT that looks like this:
> 
> {"alg":"RS256"}
> .
> {
>      "jwk":{
> 	"kty": "RSA",
> a) verifies that the outer signature matches the public key, b) that the public key matches the thumbprint signed into the inner id token, and c) that the signature on the id token is valid.   It can than act as then issue a token response for the sub of the inner id token
> 
> Look correct?
> 
> -cmort
> 
> 
> 
> On Sun, Apr 13, 2014 at 9:31 AM, Chuck Mortimore <[email-masked]> wrote:
> 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:
> 
> {
>      "sub": "https://login.salesforce.com/id/00D30000001bZxaEAE/00530000009UVC0AAO"
>      "aud": "3MVG99OxTyEMCQ3gXuX31lysX3RQP4.Vj3EVzlMsVbxFvUe7VjZ0WcjWvGlAU7BPJFZBSyBGPiGyHhojZ2BE3",
>      "exp": 1397352138,
>      "iat": 1397352018,
>      "cnf":
> 	 	{
> 			"keys":[
> 				{
> 					"kty": "RSA",
> 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
> 
> 
>