Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

Brian Campbell <bcampbell@pingidentity.com> Wed, 23 April 2014 22:38 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C891A070B for <oauth@ietfa.amsl.com>; Wed, 23 Apr 2014 15:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level:
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 n7s0Qi2obI7U for <oauth@ietfa.amsl.com>; Wed, 23 Apr 2014 15:38:05 -0700 (PDT)
Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id 56F161A029F for <oauth@ietf.org>; Wed, 23 Apr 2014 15:38:05 -0700 (PDT)
Received: from mail-ie0-f173.google.com ([209.85.223.173]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKU1hAx2qv/HPVabVz/HpZR2pGvM7bNxaX@postini.com; Wed, 23 Apr 2014 15:37:59 PDT
Received: by mail-ie0-f173.google.com with SMTP id rl12so1623838iec.32 for <oauth@ietf.org>; Wed, 23 Apr 2014 15:37:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OH7WYZvmUMAcUet1HARS9KPSTSnh4iRkJkEk5Rcyqcw=; b=lO1Nb/JtbXfk5pHIsIk9DkQ3lkZnOdc8Zw7cyfGFnyJCQQxmporJCoRDUEtvjHv6xc EJK9IK3TCG48+2Yy6sqzbKGAvVzmvAzDi+j6AkmVQmy3aB8zgir2yKXiiydMXn/FO9EF yJWsnWpT9Fa4YPUxUmGBc+vfsfqRkOzK0ax3JSD0e9jT69+PuH3+3P/Rz+sWyER/0b21 +XBtglWRaWhfjotstPWjCrPpqT24AIPfJaA6OQ8vlp3QTRIIgfXwQRF1zL1Z/wHbE3X1 NvvsEiUyLVVZSI7B67ok5UqfkivBxvq1Zur5NoVvC4kF7pyQkknc8JIsGAM1XlBPpaj6 +3Xg==
X-Gm-Message-State: ALoCoQl/M+ckLxdp9p0kn1JMtNoL5uVdZX0VSQqQxrES2QB9Q1HNpoKAF09ujuzmMT440OmuVKAO8iHXd2iQQTv6sNx5dS/+octsehSis7p8xLpQHLDfMdy7zmCOpF+Q+H9FTuCMMxrd
X-Received: by 10.42.173.68 with SMTP id q4mr45070074icz.41.1398292679313; Wed, 23 Apr 2014 15:37:59 -0700 (PDT)
X-Received: by 10.42.173.68 with SMTP id q4mr45070067icz.41.1398292679218; Wed, 23 Apr 2014 15:37:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.240.201 with HTTP; Wed, 23 Apr 2014 15:37:29 -0700 (PDT)
In-Reply-To: <53577C41.2090606@gmx.net>
References: <53577C41.2090606@gmx.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 23 Apr 2014 16:37:29 -0600
Message-ID: <CA+k3eCSmVo__OBn7vMoSZ2POeFLUS11y+BNOPTX5b=5C_OpfBg@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary=90e6ba6e863a6ff4b604f7bd62c9
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/2j2j-JdSGIesg8eQMxHWmUBKq2A
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue
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: Wed, 23 Apr 2014 22:38:08 -0000

That thread that Antonio started which you reference went on for some time (
http://www.ietf.org/mail-archive/web/oauth/current/threads.html#12520) and
seems to have reached consensus that the spec didn't need normative change
and that such privacy cases or other cases which didn't explicitly need a
subject identifier would be more appropriately dealt with in application
logic: http://www.ietf.org/mail-archive/web/oauth/current/msg12538.html




On Wed, Apr 23, 2014 at 2:39 AM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Hi all,
>
> in preparing the shepherd write-up for draft-ietf-oauth-jwt-bearer-08 I
> had to review our recent email conversations and the issue raised by
> Antonio in
> http://www.ietf.org/mail-archive/web/oauth/current/msg12520.html belong
> to it.
>
> The issue was that Section 3 of draft-ietf-oauth-jwt-bearer-08 says:
> "
>    2.   The JWT MUST contain a "sub" (subject) claim identifying 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.
> "
>
> Antonio pointed to the current Google API to illustrate that the subject
> is not always needed. Here is the Google API documentation:
> https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>
> The Google API used the client authentication part (rather than the
> authorization grant), in my understanding.
>
> I still believe that the subject field has to be included for client
> authentication but I am not so sure anymore about the authorization
> grant since I could very well imagine cases where the subject is not
> needed for authorization decisions but also for privacy reasons.
>
> I would therefore suggest to change the text as follows:
>
> "
>    2.   The JWT contains a "sub" (subject) claim identifying the
>         principal that is the subject of the JWT.  Two cases need to be
>         differentiated:
>
>         A.  For the authorization grant, the subject claim MAY
>             be included. If it is included it MUST identify the
>             authorized accessor for whom the access token is being
>             requested (typically the resource owner, or an authorized
>             delegate). Reasons for not including the subject claim
>             in the JWT are identity hiding (i.e., privacy protection
>             of the identifier of the subject) and cases where
>             the identifier of the subject is irrelevant for making
>             an authorization decision by the resource server.
>
>         B.  For client authentication, the subject MUST be the
>             included in the JWT and the value MUST be populated
>             with the "client_id" of the OAuth client.
> "
>
> What do you guys think?
>
> Ciao
> Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>