Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)
John Bradley <ve7jtb@ve7jtb.com> Sun, 13 April 2014 15:34 UTC
Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5731A01DC for <oauth@ietfa.amsl.com>; Sun, 13 Apr 2014 08:34:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSqaC4JO3log for <oauth@ietfa.amsl.com>; Sun, 13 Apr 2014 08:34:48 -0700 (PDT)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 368951A02CA for <oauth@ietf.org>; Sun, 13 Apr 2014 08:34:47 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id k15so7310106qaq.29 for <oauth@ietf.org>; Sun, 13 Apr 2014 08:34:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=BvMFSpN662h5zohgiRk5UdP3D9HvlgOQC2uVGzBhBho=; b=bqHMgjNWKUKYi+NYrXqXNRybq5yViRoYmaC8+2bndAOuhvLWsgs+Bh1mFmak8tTGM1 ZtlixxSC1QcrO3GVlA7iejHAQiUFO5FO1vbN8B5E3ejVOk6W5XzbdEoTeN5+KqbtdPjm 9N8XEu96oDrFzjYThD/vRRM/5N7wQfneqedFncmoHqeGT7iV2544tBzj3gGBT9T9AQxc K9eeS1QJ8pM2eXKihWuKtFraQWYtW0GreHuhrTvxOCcDjkgot0TABp91XAuxk/ZGWeZw 0REqmSAAEylb/Jw4aaNZto3M401X6ZTzctKIQmxguvPmLSik0QWXdMGtXKaWLJlqMj3+ NW4g==
X-Gm-Message-State: ALoCoQmnYLa2G//TjNLTnxj26JI9gjKoCs8SWmePhDlDz/039brgGAOxsgwYWQAw6qRNC2c1Koo1
X-Received: by 10.140.16.198 with SMTP id 64mr41712726qgb.10.1397403285583; Sun, 13 Apr 2014 08:34:45 -0700 (PDT)
Received: from [192.168.1.216] ([190.22.119.198]) by mx.google.com with ESMTPSA id k9sm25948631qat.18.2014.04.13.08.34.30 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Apr 2014 08:34:45 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8D4613E5-C4BB-45B3-BF88-CBF1487BCBAE"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439A15609B@TK5EX14MBXC286.redmond.corp.microsoft.com>
Date: Sun, 13 Apr 2014 12:34:04 -0300
Message-Id: <C782E37A-A38D-4C12-8029-B5934ADA3977@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B16804296739439A132083@TK5EX14MBXC286.redmond.corp.microsoft.com> <CA+wnMn_LBojNz+LCTTQN62P_U7Rag0rot715c7XCOcXAQJmEhA@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439A155FFB@TK5EX14MBXC286.redmond.corp.microsoft.com> <CA+wnMn-Dto7ySgNgMu5rkqyzfok1BWdS7WxB18ep+Uv0sFRsuw@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439A15609B@TK5EX14MBXC286.redmond.corp.microsoft.com>
To: Michael Jones <Michael.Jones@microsoft.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/iHre33HulhLZ3XD29dLV1GXMVns
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Apr 2014 15:34:53 -0000
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
- [OAUTH-WG] Proof-Of-Possession Semantics for JSON… Mike Jones
- Re: [OAUTH-WG] Proof-Of-Possession Semantics for … Manger, James
- Re: [OAUTH-WG] Proof-Of-Possession Semantics for … John Bradley
- Re: [OAUTH-WG] Proof-Of-Possession Semantics for … Mike Jones
- Re: [OAUTH-WG] Proof-Of-Possession Semantics for … Chuck Mortimore
- Re: [OAUTH-WG] Proof-Of-Possession Semantics for … Mike Jones
- Re: [OAUTH-WG] Proof-Of-Possession Semantics for … Chuck Mortimore
- Re: [OAUTH-WG] Proof-Of-Possession Semantics for … Mike Jones
- Re: [OAUTH-WG] Proof-Of-Possession Semantics for … John Bradley
- Re: [OAUTH-WG] Proof-Of-Possession Semantics for … John Bradley
- Re: [OAUTH-WG] Proof-Of-Possession Semantics for … Chuck Mortimore
- Re: [OAUTH-WG] Proof-Of-Possession Semantics for … Chuck Mortimore
- Re: [OAUTH-WG] Proof-Of-Possession Semantics for … John Bradley