[OAUTH-WG] aud, JAR, PoP key distro, etc. (was Re: IETF 93 OAuth WG Meeting Minutes)

Brian Campbell <bcampbell@pingidentity.com> Fri, 06 November 2015 22:57 UTC

Return-Path: <bcampbell@pingidentity.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 45A491A8AB3 for <oauth@ietfa.amsl.com>; Fri, 6 Nov 2015 14:57:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TtsBU9CBI2Sr for <oauth@ietfa.amsl.com>; Fri, 6 Nov 2015 14:57:19 -0800 (PST)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2E21A8AC0 for <oauth@ietf.org>; Fri, 6 Nov 2015 14:57:19 -0800 (PST)
Received: by ioc74 with SMTP id 74so71423344ioc.2 for <oauth@ietf.org>; Fri, 06 Nov 2015 14:57:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=ZV3CX08h5pZ3f8URqCzZY9kS9iNL/qPk9O5GC6nZXY0=; b=IklYVsOMIQiW0kjxhHsX1IM+km1RgdzXlsI/5jJiVDfZgAtC3ydbmiw55b/Dso8Ek/ VqTPsL033aHHOayTqmbXVoYayOOqLogu1qMfbYFvrgWYO/pfAjKSIdhiqCqgLxmJEVOG 4e7b6sTXtwbJEKmgR69s6iK3CT1uedqKukuJQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=ZV3CX08h5pZ3f8URqCzZY9kS9iNL/qPk9O5GC6nZXY0=; b=GkwaF9D+UUvJh0m0DY/rGS/Zc1M+epxeD1xSsWrfpLa5eGr6jnkOtghyuHPCTOj8de cpxv2qsEXrHN4Aiq9OZdOAPaZNj8EpiTfMn+kqyQ9MDAXlCmfGTBMbjbcfqVvBpz3I12 VFaEy5uwgbS5KV8aLI3+cue+NRD3lzOEsxkP/kU2LHhdGAukvrCclPuXs0Tyn0yYaM8s qIIqg9PPn52Vy7a4qbftkRGOejtNbvy+RFH3OwBmiEDky59C6tcGg4MkOHb5I1ljDXpL Er/6RaZ6d2G0r4NAMN+skwYGFlEB24PAB4iD2Br4YJ+yyAhTc4AH1LGIMZipyPOcmlah 7dIQ==
X-Gm-Message-State: ALoCoQlp+WuZRvdRkgfhrup2l68nXlwVPO0i8R/zlKm4J7ZkAdvnRp2GD5hD/GcyAPGRhFuMr3lG
X-Received: by with SMTP id 24mr13293363ioh.48.1446850638598; Fri, 06 Nov 2015 14:57:18 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 6 Nov 2015 14:56:49 -0800 (PST)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 06 Nov 2015 15:56:49 -0700
Message-ID: <CA+k3eCRsWTJ5b5GLxoOg-XCnhifH6ZAFEm6wSQZwvbyEizuzSg@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary="001a113f8b825b6dc50523e72a1b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/xxbSxs2GzKKAb5rRtjPSu9cJwz8>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: [OAUTH-WG] aud, JAR, PoP key distro, etc. (was Re: IETF 93 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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 06 Nov 2015 22:57:21 -0000

That's right, sorry, there's not actually a conflict now as the PoP key
distribution draft currently only uses the 'aud' parameter at the token

I just assume it will end up being used at the authorization endpoint
eventually because the need to disambiguate where the token will be used
isn't limited to the token endpoint (we do have this implicit thing). As
John mentioned, we have used an 'aud' parameter (interpreted as a resource
location) in our AS on both endpoints to allow the client to indicate where
it intends to use the token it's asking for, which enables the AS to apply
unique policy to that token for the given resource (it's not the exact same
thing as PoP key distribution but conceptually similar). So I was confusing
implementation experience with what was actually in the PoP key
distribution draft.

That said, I do think that JAR should register JWT claims that it's likely
to use in the Request Object as authorization endpoint parameters to avoid
this kind of conflict.

And I something like the 'aud' parameter is needed at both the token and
authorization endpoints so  PoP key distribution should use a different
name. Or this potential independent draft, which I do think has value. I
was planning on proposing something that's based on similar parameters
being worked on in token exchange - we're just not there quite yet.

On Fri, Nov 6, 2015 at 6:03 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net
> wrote:

>         Brian also pointed out that there is a conflict with the PoP key
> distribution draft that uses the 'aud' parameter. John noted that
> currently the 'aud' parameter is used towards a different endpoint, used
> as a query parameter, but it would probably be good to take this into
> account now.
>         Justin noted that there is general utility to indicate the
> audience.
> Today people are forced to use the scope for WHAT, HOW and HOW LONG the
> client wants to access a protected resource. The 'aud' describes the
> WHAT aspect.  He suggested to take it a general utility extension that
> is indepdent of the PoP document.
>         Hannes added a remark that the 'aud' parameter / claim was a
> separate
> document and then we added it to the PoP document.
>         John said that we didn't had the wide-enough picture and we now
> understand things better.