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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 24 April 2014 07:11 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 762971A0129 for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 00:11:38 -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 0qkHZDUN9ov0 for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 00:11:35 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id A84B51A00AE for <oauth@ietf.org>; Thu, 24 Apr 2014 00:11:34 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LxLcc-1WxRcz0Rha-016xTk; Thu, 24 Apr 2014 09:11:27 +0200
Message-ID: <5358B8BC.8000508@gmx.net>
Date: Thu, 24 Apr 2014 09:09:48 +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: Brian Campbell <bcampbell@pingidentity.com>
References: <53577C41.2090606@gmx.net> <CA+k3eCSmVo__OBn7vMoSZ2POeFLUS11y+BNOPTX5b=5C_OpfBg@mail.gmail.com>
In-Reply-To: <CA+k3eCSmVo__OBn7vMoSZ2POeFLUS11y+BNOPTX5b=5C_OpfBg@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FROQIoNb2KRBeA6w0UmJtWx11fBJjptLu"
X-Provags-ID: V03:K0:S+nEjrQdI5L6sR/tY/pJ8eL2OS732LHaERYQgAZgK58T/3t4Jjm azKqGt9ZZKRMb2UmSBk7aXShPUjaz1+Jh0A0yyevJjbZJ7JeVqwQlucf5mzA73fJ47ceER5 i+PJ4qFUhhEHQOyK7V4RcWp/D8N4uxbtdejsXuTgYxX0dXC1C+lPsoEpjbawqUVAdERAbbf AujpP3r+Sy3p9Jquee86g==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JF-YDSc0w7vWYN0qYdch3aDVJ2I
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: Thu, 24 Apr 2014 07:11:38 -0000

Hi Brian,

I read through the thread and the Google case is a bit different since
they are using the client authentication part of the JWT bearer spec.
There I don't see the privacy concerns either.

I am, however, focused on the authorization grant where the subject is
in most cases the resource owner.

It is possible to put garbage into the subject element when privacy
protection is needed for the resource owner case but that would need to
be described in the document; currently it is not there.

Ciao
Hannes


On 04/24/2014 12:37 AM, Brian Campbell wrote:
> 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 <mailto: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 <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
> 
>