IETF Logo Mail Archive

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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 23 April 2014 08:42 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 084D01A013A for <oauth@ietfa.amsl.com>; Wed, 23 Apr 2014 01:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level:
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 1K7W7nSQQgjw for <oauth@ietfa.amsl.com>; Wed, 23 Apr 2014 01:41:55 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1181A0139 for <oauth@ietf.org>; Wed, 23 Apr 2014 01:41:55 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MQeET-1WUnC919Hp-00U3og; Wed, 23 Apr 2014 10:41:44 +0200
Message-ID: <53577C41.2090606@gmx.net>
Date: Wed, 23 Apr 2014 10:39:29 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "oauth@ietf.org" <oauth@ietf.org>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="M6KfA2q6Ui6C9bCVQEtj7anao85JrOKm7"
X-Provags-ID: V03:K0:wFFe5g3TvBB3iAYycZq2CLx/4J2vcII79yu5corM3BOR5RBj2gZ x8OrpO8Jq63yotTAT09GeSg19ZV/sTVFRgtxMd7l2mGVEY2UpCM+7Q9kieZSLGSme4fQ8ok GNUHso4rTde+XpJySBWyqbHgxcc4LI/LinXdBhIObrRcN0ci5liR3P0XDbhHN+qzE7lDq4r LnZa3mVcqLKx3ievDVccg==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TeLiGA9zbLptHCAAc1mNleyaDY0
Subject: [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 08:42:03 -0000

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

v2.23.0 | Report a Bug | By Email