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

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 <Michael.Jones@microsoft.com> wrote:

> Can you sketch out what data structures you’d ideally use for your scenario and what the elements mean?
>  
> From: Chuck Mortimore [mailto:cmortimore@salesforce.com] 
> Sent: Saturday, April 12, 2014 8:39 PM
> To: Mike Jones
> Cc: oauth@ietf.org
> 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 <Michael.Jones@microsoft.com> 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:cmortimore@salesforce.com] 
> Sent: Saturday, April 12, 2014 6:12 PM
> To: Mike Jones
> 
> Cc: oauth@ietf.org
> 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 <Michael.Jones@microsoft.com> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
>  
>  
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth