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