[OAUTH-WG] oauth-pop-key-distribution

John Bradley <ve7jtb@ve7jtb.com> Tue, 13 January 2015 23:26 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 494571A87D5 for <oauth@ietfa.amsl.com>; Tue, 13 Jan 2015 15:26:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AWthbAurxi5X for <oauth@ietfa.amsl.com>; Tue, 13 Jan 2015 15:26:21 -0800 (PST)
Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F761A1A86 for <oauth@ietf.org>; Tue, 13 Jan 2015 15:26:20 -0800 (PST)
Received: by mail-qg0-f42.google.com with SMTP id q108so4729156qgd.1 for <oauth@ietf.org>; Tue, 13 Jan 2015 15:26:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=kD1Soq6uVIaH8LTBmJIDW6/1vNj3rPZFOBIOTxB+83o=; b=lWom37/zaTFu3UUX+orVwnBPc8n66QgVztMZ6ADJsCTpe/fM9Qi24FkogM2gl3ZN5d KPFZpoOClQ9m5VC1+injpGxy+KcFG5bh3elbg01kPMUDTuEi/W3SjGIXGU/C8urC3gUQ hBxv27uhgNhla4Ysj5QnyOHjJSd3DwLw8mZsM/OuFqYHgEGZA3GsFOeuUPzSTEOWdp9P j2TvQlq1xNZZxf/xHWQ/o+xemG6isZ66x2pB0AQaHJgxcx8AsMb+XgtpUIJbt/H2a/zx 6Vn+TO33BY2da4X+7JsM2Oh2fhxJxqj2/R2E2XBPzEcK0c3RBgANDihd8f/Rzg95f4DS Tgbw==
X-Gm-Message-State: ALoCoQlKHRRAPpvgZRFe550oIPM7Ye28FN6On60bvDzm1kbfk4xMxX2n3ur9CwVvqju9sgrbX9aa
X-Received: by with SMTP id it3mr2023593qcb.24.1421191579969; Tue, 13 Jan 2015 15:26:19 -0800 (PST)
Received: from [] ([]) by mx.google.com with ESMTPSA id j101sm18976290qge.10.2015. for <oauth@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Jan 2015 15:26:19 -0800 (PST)
From: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_15AA85C3-D229-4C09-83C2-F5C16041E7EB"; protocol="application/pkcs7-signature"; micalg="sha1"
Message-Id: <0C9709D9-42BE-4971-A1AD-9825811C69D7@ve7jtb.com>
Date: Tue, 13 Jan 2015 20:26:15 -0300
To: OAuth WG <oauth@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
X-Mailer: Apple Mail (2.1993)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/mMUuGj-SBVZQAynUH_LxvfToyMk>
Subject: [OAUTH-WG] oauth-pop-key-distribution
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: Tue, 13 Jan 2015 23:26:24 -0000

Looking at the text I noticed that.Sec 4.2 has an example that contains a JWE as a key but a comment that the remainder of the plain JWK is omitted.   

That should probably be JWE.

We should probably also have an example with the jwk object inline.

One thing I think we have as a gap is that public clients have no real protection for the refresh token. 

Anyone intercepting any call to the token endpoint  for a new AT will get the RT and be able to get new POP keys for the AT.

We don't currently have any examples in the spec of getting a key based on a RT but it is required if you are using symmetric keys with multiple RS.

One thing that might work is to only provide a key to public clients with the authorization_code grant_type.
That protects the RT from being used if it is leaked by the app.

I think Chuck Mortimore suggested on the list that the public client could provide a public key as part of the initial Authz request, and that key would be used to encrypt the token keys to the client.
That is probably the most secure but would cause spop (yes we will rename it) to intersect with pop key distribution.

eg define a new code_challenge_method that sends a "jwk" as the code_challenge and a signed jwt to the token endpoint as the code_verifier.   
Then using the code_challenge public key to encrypt the per AT key.

That would be an extension of spop if we want to do it.

At the moment I think the pop story for public clients/native apps is a bit weak.  

If people give me feedback plus any other updates for the key distribution spec I will rev it over the next couple of days, as it needs to be refreshed to keep it active.

John B.