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

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 <cmortimore@salesforce.com> 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 
> 
> 
> 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