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

Brian Campbell <bcampbell@pingidentity.com> Mon, 04 November 2013 18:45 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 1069F21E8160 for <oauth@ietfa.amsl.com>; Mon, 4 Nov 2013 10:45:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.906
X-Spam-Level:
X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.071, 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 hpMfSwxIUPAi for <oauth@ietfa.amsl.com>; Mon, 4 Nov 2013 10:45:01 -0800 (PST)
Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id BDD4221E805F for <oauth@ietf.org>; Mon, 4 Nov 2013 10:44:51 -0800 (PST)
Received: from mail-ie0-f179.google.com ([209.85.223.179]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKUnfrI95ICp6RAVwWhQI7B98QvaPaCXqp@postini.com; Mon, 04 Nov 2013 10:44:51 PST
Received: by mail-ie0-f179.google.com with SMTP id aq17so12622180iec.24 for <oauth@ietf.org>; Mon, 04 Nov 2013 10:44:51 -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=OCal8ubfNAorHoprbEgrVqNMjjcNmcxJYzyWxcyvgzY=; b=YZQ91DCWEaKZE3K+GHBAp5Ep3sY+tqjdjrjIgh3DY312+uPU4S7zoRQcTI96GQyDtr ga/iB2AIPbLLRkDtLk3VpaqOw1H2oSaxnHjDGGWaR7JWYKHzdMKsEpWUtS6JwQ4eAN9i C6g9hl5/MDls8U1wgsVjdwqAkRmnOApyiV2FtahDw49u7rGBRfAMDPXZuM6WS+5G8hCU XFhiPfJSmQsLnM7KwDqeRV7Z/uzCICg2RaEKwNOTVJVjxEU2HUTrEqXn6rU7h+ln1bZo +8LVDNuULK7p6VUlnZFAHJGkvGE8UZNn+1cHhGTUlWThW6p3EOYrX5yu1BcZ/cnrp731 KeDA==
X-Gm-Message-State: ALoCoQlNDY5sfTQMp2c66coQ4gOvkuhmNn+jiL/lGF1b7+SO8OV2k3uldeiJom4XMfgrEC9c1le1K/E0b8y1wbnumYh+QNXtn3WGmkBMVfPFxO4ZgcDWYctqK6TeciTZC+PkNgbIdasK1Y1GNy1VHkop6vS2ERcuLA==
X-Received: by 10.43.180.200 with SMTP id pf8mr1680959icc.50.1383590691300; Mon, 04 Nov 2013 10:44:51 -0800 (PST)
X-Received: by 10.43.180.200 with SMTP id pf8mr1680953icc.50.1383590691229; Mon, 04 Nov 2013 10:44:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 10:44:21 -0800 (PST)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 4 Nov 2013 10:44:21 -0800
Message-ID: <CA+k3eCQH-QXFUD_uTPu4vz_Q7c5ekcNbNj-_53Ensf=efuycWQ@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] subject (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:45:07 -0000

On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:
> You write:
> "
>    2.   The JWT MUST contain a "sub" (subject) claim identifying the
>         subject of the transaction.  The subject MAY identify the
>         resource owner for whom the access token is being requested.
>
>         A.  When using a JWT as an authorization grant, the subject
>             SHOULD identify an authorized accessor for whom the access
>             token is being requested (typically the resource owner, or
>             an authorized delegate).
>
>         B.  For client authentication, the subject MUST be the
>             "client_id" of the OAuth client.
> "
>
> Should this rather read:
>
> "
>    2.   The JWT MUST contain a "sub" (subject) claim identifing the
>         principal that is the subject of the JWT. Two cases need to
>         be differentiated:
>
>         A.  For the authorization grant, the subject
>             SHOULD identify an authorized accessor for whom the access
>             token is being requested (typically the resource owner, or
>             an authorized delegate).
>
>         B.  For client authentication, the subject MUST be the
>             "client_id" of the OAuth client.
> "

Agreed that reads better.

> Why isn't the SHOULD under (A) actually a MUST? Then, the current text in A
> is so fuzzy that it actually doesn't allow someone to create a test case to
> test whether an implementation is interoperable or not. With B the situation
> is different. Is there something else we can say for A?

The fuzziness of the text in A, I believe, comes from use cases where
the principal wouldn't directly be identified in the sub claim. For
example, a JWT with an anonymous subject and a claim stating they are
a member of a particular group might be sufficient to grant access to
some types of resources (this is discussed in
http://tools.ietf.org/html/draft-ietf-oauth-assertions-12#section-6.3.1).
It is also not uncommon, in this federated scenarios, for additional
claims/attributes to be needed along with the subject in order to
uniquely identify the principle as known to the AS.

Is there a way to rephrase the text for A which would be more helpful
but not preclude such use cases?