Return-Path: 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 D5C711A01DA for ; Sun, 13 Apr 2014 09:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 DqV7D5P8Q0J0 for ; Sun, 13 Apr 2014 09:31:44 -0700 (PDT) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by ietfa.amsl.com (Postfix) with ESMTP id 67B581A01DC for ; Sun, 13 Apr 2014 09:31:44 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id va2so8220170obc.0 for ; Sun, 13 Apr 2014 09:31:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GVPQENbfZVwwPxw1CxrCcT2Hd6nbdTQ+aH5vWorPMOg=; b=ZJL5Ypc7JCQTSn7w7W21XqbHrwWPXs54lOskohazFCKP51kMI/XWm4/Ei7DXppbeA8 09UQFTBuozRqUGMjbmvzkJD0iprGCc/Uv3XagreGnJlWWtqMqAkn0y/MBnvbL5z+0aMT wDy+irrOK75Ef3pG2DUyaJXllmoGhpmB5GZIIwfvVm46tt6x6bxWcj1D3xFU7yBxwZ+/ eqhRIJnHaLZ+uExwg6bN1J1hmESWhchE7dhs4JaL8UPo+EntJ5Th9EzjFOx2caqDpQ5y ExV1FZLxHa/QGcgQYJv8arfc/3sRbyS44WP4/3RjX5Hu5OS40kBlNrl606lvmZgWtPnQ yaWg== X-Gm-Message-State: ALoCoQkIFx4dKHHCI96euoFQ0YD6gpehQFaunJ3TNFcl/6ZU64FRVt31P338XaBinCJ0iJf4LeZn MIME-Version: 1.0 X-Received: by 10.60.160.173 with SMTP id xl13mr30574936oeb.19.1397406702084; Sun, 13 Apr 2014 09:31:42 -0700 (PDT) Received: by 10.76.75.169 with HTTP; Sun, 13 Apr 2014 09:31:41 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739439A132083@TK5EX14MBXC286.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439A155FFB@TK5EX14MBXC286.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439A15609B@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Sun, 13 Apr 2014 09:31:41 -0700 Message-ID: From: Chuck Mortimore To: John Bradley Content-Type: multipart/alternative; boundary=089e011764e915b50404f6ef1ad7 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/yR4KUEidNLPUHr9BFWzbTheo6e8 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 16:31:49 -0000 --089e011764e915b50404f6ef1ad7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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.Vj3EVzlMsVbxFvUe7VjZ0WcjWvGlAU7BPJFZBSyBGPi= GyHhojZ2BE3", "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 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. > 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 > 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 tha= t > 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 > 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 define= d > 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 > wrote: > I've written a concise Internet-Draft on proof-of-possession for JWTs wit= h > 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 t= he > 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 structu= re > to be used by other specifications that do define those things. > > The specification is available at: > > =B7 > http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-00 > > An HTML formatted version is available at: > > =B7 > http://self-issued.info/docs/draft-jones-oauth-proof-of-possession-00.htm= l > > -- Mike > > P.S. This note was also posted at http://self-issued.info/?p=3D1210 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 > > > --089e011764e915b50404f6ef1ad7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes - sounds about what I'm looking at

<= div>For the scenario, we'd have a client talking to our authorization s= erver 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. &nb= sp;  Both would be able to prove possession using their own keys witho= ut sharing.    So to answer mike's data structure question, i= t 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 author= izes, and mints new id token as jwk set containing both the dynamically gen= erated client key and also the cert for its server:

{
     "aud": "3MVG99OxTyEMCQ3gXuX31lysX3R= QP4.Vj3EVzlMsVbxFvUe7VjZ0WcjWvGlAU7BPJFZBSyBGPiGyHhojZ2BE3",
     "exp": 1397352138,
    &= nbsp;"iat": 1397352018,
     "cnf":
  {
"= ;keys":[
{
"kty"= : "RSA",
= "n": "AKPBc9I142dEc-Srdk5sz9MVaJH_k....",
"e": "= ;AQAB",
"alg": "RS256"
},
{
"x5c":["M= IIDQjCCAi...."]        
}
]
}
} 


The id token can then be presented to something like our oau= th 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 capabili= ties 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.inn= ersignature).outersignature

-cmort



On Sun, Apr 13, 2014 at 8:34 AM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:
I think = Chuck is largely referring to the scenario that Connect supports for issuin= g id_tokens for 3rd parties but where the 3rd party also wants a access tok= en to access the API.

This is similar to the Google Play / NAAPS use case, but wit= h 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 a= ctivity.
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 regi= stered and ads complexity for symmetric keys.
3 Give client an as= sertion that can be used by the related backend to get it's own AT, all= owing the clients to have different client_id and proof keys. (builds on Co= nnect 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:&nb= sp;Chuck Mortimore [mailto:cmortimore@salesforce.com] 
Sent: Saturday, April 12, 2014 8:39 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject:<= /b> Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON= Web Tokens (JWTs)
 
 
-cmort 

 

On Sat, Apr 12, 2014 at 8:32 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
<= div>
Is having multiple confirmation keys a commo= n case?  I’d rather we “make simple things simple” t= han build the most general solution possible.  If an application reall= y needs multiple confirmation keys, it can always defined a “jwks&rdq= uo; element and the handling rules for it, and go for it…<= /u>
 
           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;           -- Mike
 
From: C= huck Mortimore [mailto:cmortimore@sa= lesforce.com] 
Sent: Saturday, April 12, 2014 6:12 PM
To: Mike Jones
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 t= hat the recipient can cryptographically confirm proof-of-possession of the = key by the presenter. This property is also sometimes described as the pres= enter being a holder-of-key.
 
Thi= s specification intentionally does not specify the means of communicating t= he proof-of-possession JWT, nor the messages used to exercise the proof key= , as these are necessarily application-specific.  Rather, this specifi= cation defines a proof-of-possession JWT data structure to be used by other= specifications that do define those things.
 
The= specification is available at:

=B7=         http://tools.ietf.org/html/draft-jones-oauth-proof-of-p= ossession-00

 
An = HTML formatted version is available at:

=B7=         http://self-issued.info/docs/draft-jones-oauth-p= roof-of-possession-00.html

 =
      =             &nb= sp;            =             &nb= sp;            =     -- Mike
 
P.S.  This note was a= lso posted at http:= //self-issued.info/?p=3D1210 and as @selfissued.
 


_______________________________________________
OAuth mailing listOAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 
 
_____________________________________= __________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th


--089e011764e915b50404f6ef1ad7--