[OAUTH-WG] Meeting Minutes

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 31 March 2015 09:08 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 E60641A0210 for <oauth@ietfa.amsl.com>; Tue, 31 Mar 2015 02:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.51
X-Spam-Level:
X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1b-iVf3IMO1c for <oauth@ietfa.amsl.com>; Tue, 31 Mar 2015 02:08:52 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA20E1A0108 for <oauth@ietf.org>; Tue, 31 Mar 2015 02:08:51 -0700 (PDT)
Received: from [192.168.131.145] ([80.92.114.249]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MKu9E-1YcsAC0f5c-00051L for <oauth@ietf.org>; Tue, 31 Mar 2015 11:08:48 +0200
Message-ID: <551A641F.8050909@gmx.net>
Date: Tue, 31 Mar 2015 11:08:47 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "oauth@ietf.org" <oauth@ietf.org>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="ms9JAc9iof9Xr4rGQvqIDWtHfn2EX4DLb"
X-Provags-ID: V03:K0:AnMo469eHlYk0ayZ+B+Bv8QjO12MJ39MHDWU2Q/qF2rHf90S2+H 3tcySi6d58yxwZJ0JnGUI5gtFOH2txuCXtW9KEl/MSr3E3EjBAAnNY1orIifB7pD9tE1WYm BsXQkvoLLV3OsuZNXqtWUx+jXD3d2Cr3KG9kv92+auL9deaf18yBQ7lipd9YqR2fbR/m0U3 XhbErbCTdZhWjt+lvk9cA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/vUjNwlDLOU2qmJTZc3qCrImPp9g>
Subject: [OAUTH-WG] Meeting Minutes
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, 31 Mar 2015 09:08:54 -0000

The minutes from our OAuth f2f meeting have been uploaded to
http://www.ietf.org/proceedings/92/minutes/minutes-92-oauth

Thanks to Tony for taking notes.

Ciao
Hannes & Derek

---------------------------------

OAUTH WG

WG STATUS
Oauth Assertion Framework – RFC Editor Queue
JWT - RFC Editor
JWT Bearer  - RFC Editor

Proof Key for code exchange – to IESG
PoP Architecture – to IESG
PoP Semantics for JWT WGLC in Progress
Token Introspection – Shepherd write up

Token Introspection – Justin
Made changes from WGLC most notably some specific requirements for “active”
Open Issues: Registries
Main issues is trying use the JWT registry with Token Introspection, so
there is a (1) proposal to extend the JWT registry or (2) to create a
new registry and seed it with the JWT registry,  (3) and last proposal
is to create a new introspection registry-only
Mike – is for option2 to be aligned with how this has been done before
Brian – 2 separate registries are needed, so option 2 would work
John – Does not want the JWT to be a dumping ground, so separate
registries needed
Poll – option 1 – 0 votes, option 2 – 12, option 3 -1



POP Semantics – Mike
WGLC ends soon, new comments came in so need to talk about these and
push a new draft out
Brian – Made some editorial comments, concerns over the CNF and the
structure.
Review document – Justin, Nat

John Bradley gave overview of Proof of Possession
Proof-of-Possession Blog post from John Bradley see
http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.html
Discussion over how to stay in step with the industry, other ietf work


PoP AS to Client Key Distribution  - Hannes and John Bradley
Open Issues – can asymmetric keys be used with more than one resource server
Protect Refresh Token as well as Access token ? TBD, need usecase
Need to have more discussions on client held keys and server keys
There needs to be a matrix of all the options that may be available
(will call out the various redundancies)

HTTP Message signing
Tie and OAUTH token and signature to a specific HTTP request
This is not binding to the TLS session
There are other ways to do this, OAUTH 1.0 and AWS

OAUTH Token Exchange
ActAS, onBehalfOf functionality
Stable drafts
Need more input and more eyes on this
Phil – so folks are not interested in the expensive token chains and
validating
Brian – none of his feedback has been considered

In-official meeting will be scheduled during this week.

Open Redirectors
Leaks  information in the fragment and referrer, this applies to all
protocols that use redirects
Some of the mitigations
              Append fragments to all redirects
              Internal redirect
              Append content-security-policy Header
              Include Referrer meta tag
So do we do something specific in OAUTH like put this into the security
document

Suggestion to update the OAuth Thread document to include these types of
recommendations. No decision made.

Destination Claim – Brian
A new claim for specifying the destination of the JWT, not the same as
audience (who) but where is the key,
A single value destination, may need to make this a multi-value

Discussion needed how it is different to the audience claim.

End of meeting