[OAUTH-WG] audience (was draft-ietf-oauth-jwt-bearer-06)

Brian Campbell <bcampbell@pingidentity.com> Mon, 04 November 2013 18:46 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A846B21E8153 for <oauth@ietfa.amsl.com>; Mon, 4 Nov 2013 10:46:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.912
X-Spam-Level:
X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1qmGdclBYYN for <oauth@ietfa.amsl.com>; Mon, 4 Nov 2013 10:46:04 -0800 (PST)
Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 494BB21E805F for <oauth@ietf.org>; Mon, 4 Nov 2013 10:45:54 -0800 (PST)
Received: from mail-ie0-f177.google.com ([209.85.223.177]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKUnfrYclf5oGs4vhAj2/E4WNqtzlCrZmY@postini.com; Mon, 04 Nov 2013 10:45:55 PST
Received: by mail-ie0-f177.google.com with SMTP id e14so13071971iej.36 for <oauth@ietf.org>; Mon, 04 Nov 2013 10:45:53 -0800 (PST)
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=nr/g71PQ0F5dj9t2KkvIMuZD6Na4TlHZYyEpjM730AQ=; b=IRfheEjiFyi2BXnfPbeNv1xGlokFPGSNqX73+eDpoKrMzAu18A+DsUruz5qd6/+0yM ZjcjypwbHsY3uFmQ+6lnMoY2JUPjBnhSGLAfjvZMm4bZ9UqN7Ycj3pIOsPwbC6Y2AbgW 3rEPml1osogl/tw2urWWfdWt/Awo5D+I2x+6kvC8TLfEEepEP2psw3JP3Qax7toguBll bTC2cMSkbhaX6p9kK29Jj2PklFLufQ+icXYmjPYZvwxBd7K9mVQ+wJ785wH8cHGUmm7C 2QSniJbwXNBAPdy6s3FczZ5KjF3rTTkBu5LfSVkUw8GANFvuyA4L7/AoNIsqOq8du9CS T9NQ==
X-Gm-Message-State: ALoCoQnwKJbRFKUcdgfyHFtEhLcJ2pw0jL/r5yj7t2lc6xvrBqd/9C2GZqU/aqVjhS1G9buTBV131N6MEf6bSvI4jE66/5+52iSslVSZRveK1dOn+983Hx9q7/PBFgDW+GhgvXJl/bgP8piR2MKnVcWMZ5qtDIJs4Q==
X-Received: by 10.50.1.102 with SMTP id 6mr13270399igl.0.1383590753709; Mon, 04 Nov 2013 10:45:53 -0800 (PST)
X-Received: by 10.50.1.102 with SMTP id 6mr13270391igl.0.1383590753642; Mon, 04 Nov 2013 10:45:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 10:45:23 -0800 (PST)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 04 Nov 2013 10:45:23 -0800
Message-ID: <CA+k3eCQFOsMbV=8vxawtg1ts7jPngUwab8RY8ah+2A8Bh1ZjiA@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: [OAUTH-WG] audience (was draft-ietf-oauth-jwt-bearer-06)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 04 Nov 2013 18:46:11 -0000

On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:
> You write:
>
> "
>  3.   The JWT MUST contain an "aud" (audience) claim containing a
>         value that identifies the authorization server as an intended
>         audience.  The token endpoint URL of the authorization server
>         MAY be used as a value for an "aud" element to identify the
>         authorization server as an intended audience of the JWT.  JWTs
>         that do not identify the authorization server as an intended
>         audience MUST be rejected....
> "
>
> If the endpoint URL of the AS is not used then what else? Wouldn't it be
> useful to say "The token endpoint URL of the authorization server
>         MUST be used as a value for an "aud" element to identify the
>         authorization server as an intended audience of the JWT."?

This and the other assertion documents offer the token endpoint URL as
one way to identify the AS for deployments which lack some other means
of doing so. However, these assertion profiles are little slices of
functionality that augment existing deployments of OAuth, often in
conjunction with other 'federated' technologies for which there will
be an existing and agreed upon identifier that the issuer is known by.
This is not just academic - it's how these systems and deployment
already work. It's inappropriate and unrealistic for this document (or
the other assertion docs) to preclude common and useful deployment
practices.

> Then, I have a suggestion for re-phrasing this sentence from :
> "
>         Audience values SHOULD be compared
>         using the Simple String Comparison method defined in Section
>         6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the
>         application.
> "
> to:
>
> "
> In the absence of an application profile standard specifying
> otherwise, a compliant JWT Bearer application MUST compare the audience
> values using the Simple String Comparison method defined in Section
>         6.2.1 of RFC 3986 [RFC3986].
> "

I think I'm okay with that re-phrasing. Do others (my co-authors
especially) agree? Or object?

>
> The same can actually be applied to the issuer claim as well.

As I said in the previous mail about issuer, I'd like to get rid of
the comparison text. However, if such text stays, I'll work to make it
consistent throughout.

> Given that the JWT had been updated to align it with the JOSE work I suspect
> that this document also requires an update.

You may well be correct. But despite following the JOSE and JWT work,
I'm not sure I know what update(s) would be required. Can you
elaborate?