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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 24 April 2014 12:52 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 D07BB1A01D5 for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 05:52:24 -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 F6anJPo6OqQx for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 05:52:20 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 705921A0176 for <oauth@ietf.org>; Thu, 24 Apr 2014 05:52:20 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MbsV8-1WNQwX3PfC-00JNdX; Thu, 24 Apr 2014 14:52:12 +0200
Message-ID: <53590810.8000503@gmx.net>
Date: Thu, 24 Apr 2014 14:48:16 +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> <5358B8BC.8000508@gmx.net> <CA+k3eCSCtSb42pqz8qE4MQbfXzLQFr9bEAcNm0bgJ24WRL4C4Q@mail.gmail.com>
In-Reply-To: <CA+k3eCSCtSb42pqz8qE4MQbfXzLQFr9bEAcNm0bgJ24WRL4C4Q@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="41NaeWCBmvH5Dxh8uSsinvOhdq4LPww6w"
X-Provags-ID: V03:K0:s0x+H0/SV3kpzDMsB6ej3bZ2/zU38srI8O7JkQrEi/zatFlPKPR puw1qLo+BKaQnUUBQPnkLs2/9ReBxHb/GRtO+5PAUiQlWgRcqKIKnVLqErAJwJzoLLrCBxT AbRcd2VTKItz4hBLRIHlsNYtZrKVlapvrN9mKR6Hbdl25Uj2Lo99tFaZLZ5k346tICNuzi8 FXi4LSgxqCickYguuXIoQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/0LXDYkeVIywPYJB-TifEPpkwitM
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 12:52:25 -0000

Hi Brian,

Thanks for pointing to the assertion framework document. Re-reading the
text it appears that we have listed the case that in Section 6.3.1 but
have forgotten to cover it elsewhere in the document.


In Section 6.3.1 we say:

"

6.3.1.  Client Acting on Behalf of an Anonymous User

   When a client is accessing resources on behalf of an anonymous user,
   the Subject indicates to the Authorization Server that the client is
   acting on-behalf of an anonymous user as defined by the Authorization
   Server.  It is implied that authorization is based upon additional
   criteria, such as additional attributes or claims provided in the
   assertion.  For example, a client may present an assertion from a
   trusted issuer asserting that the bearer is over 18 via an included
   claim.

*****
    In this case, no additional information about the user's
   identity is included, yet all the data needed to issue an access
   token is present.
*****
"
(I marked the relevant part with '***')


In Section 5.2, however, we say:


   o  The assertion MUST contain a Subject.  The Subject identifies an
      authorized accessor for which the access token is being requested
      (typically the resource owner, or an authorized delegate).  When
      the client is acting on behalf of itself, the Subject MUST be the
      value of the client's "client_id".


What we should have done in Section 5.2 is to expand the cases inline
with what we have written in Section 6.

Here is my proposed text:

"
o  The assertion MUST contain a Subject.  The Subject identifies an
authorized accessor for which the access token is being requested
(typically the resource owner, or an authorized delegate).


When the client is acting on behalf of itself, as described in Section
6.1 and Section 6.2, the Subject MUST be the value of the client's
"client_id".

When the client is acting on behalf of an user, as described in Section
6.3, the Subject element MUST be included in the assertion and
identifies an authorized accessor for which the access token is being
requested.

When the client is acting on behalf of an anonymous user, as described
in Section 6.3.1, the Subject element MUST NOT be included in the
assertion. Other elements within the assertion will, however, provide
enough information for the authorization server to make an authorization
decision.
"

Does this make sense to you?

Ciao
Hannes


On 04/24/2014 02:30 PM, Brian Campbell wrote:
> There is some discussion of that case in the assertion framework
> document at
> http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-6.3.1
> 
> Do you feel that more is needed? If so, can you propose some text?
> 
> 
> On Thu, Apr 24, 2014 at 1:09 AM, Hannes Tschofenig
> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
> 
>     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>
>     <mailto: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> <mailto:OAuth@ietf.org
>     <mailto:OAuth@ietf.org>>
>     >     https://www.ietf.org/mailman/listinfo/oauth
>     >
>     >
> 
>