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

Brian Campbell <bcampbell@pingidentity.com> Thu, 24 April 2014 12:31 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 5A6E61A01C1 for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 05:31:29 -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 GTfO1d6D0DA1 for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 05:31:26 -0700 (PDT)
Received: from na3sys009aog135.obsmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA861A01B9 for <oauth@ietf.org>; Thu, 24 Apr 2014 05:31:26 -0700 (PDT)
Received: from mail-ig0-f181.google.com ([209.85.213.181]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKU1kEGMDr5zeWBJrf/OsSJx3pEbS6SdVZ@postini.com; Thu, 24 Apr 2014 05:31:20 PDT
Received: by mail-ig0-f181.google.com with SMTP id h18so810684igc.2 for <oauth@ietf.org>; Thu, 24 Apr 2014 05:31:19 -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=HVWxdb5p2HVv4X5rZc1fsfLJ6JB7Uw8smg0GpOtf25o=; b=QgBWjOfQi6qfHtC4DAiyPw3HH8mk4ARcrRH/23ft5JSshQwoNvssx+bHvJYTg9CqUw 359lpdD+jBUyOe9k0u6T96tCzHFKuUsbCOXcRykhw2lxUETVcOGdFwDGa6b+9ikvl1pS WRECGB6XNbiDyF0HVUZOzadOJZnhGOVmqNQr7PHiUeqsKeZe77qwpoGltHX2JeVWwJAu m/qGIAmIsuhlyweuXXYcOVglikhziNV0hOnmfJ8k1lHkOYm5TbxA/Z5Jr9hWMwycZwAS 1Yp0UcyY4emviYmdY3KB5Avpqr8BZ49G2v5WaG2KnBmyQT33ip5q74FCzuXYezkLchat 7B2A==
X-Gm-Message-State: ALoCoQmSjRMSDyWO+OUxRJoiy87B8PoTvmslu3uQucIeJSCLjnw/69rtM6ufGwjIJixJNioIXIwIt7K2QPNDaxCfCjJ2QYyl1TWncemdazGhhZjcJNCIRmEpWeDgsobDQV2gbCrGSy7T
X-Received: by 10.42.136.130 with SMTP id u2mr1451922ict.51.1398342679935; Thu, 24 Apr 2014 05:31:19 -0700 (PDT)
X-Received: by 10.42.136.130 with SMTP id u2mr1451912ict.51.1398342679832; Thu, 24 Apr 2014 05:31:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.240.201 with HTTP; Thu, 24 Apr 2014 05:30:49 -0700 (PDT)
In-Reply-To: <5358B8BC.8000508@gmx.net>
References: <53577C41.2090606@gmx.net> <CA+k3eCSmVo__OBn7vMoSZ2POeFLUS11y+BNOPTX5b=5C_OpfBg@mail.gmail.com> <5358B8BC.8000508@gmx.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 24 Apr 2014 06:30:49 -0600
Message-ID: <CA+k3eCSCtSb42pqz8qE4MQbfXzLQFr9bEAcNm0bgJ24WRL4C4Q@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary=90e6ba6e8c06b4c12f04f7c9066c
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jIxpe9aprjKSgMczukz-XsP-laA
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:31:29 -0000

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> 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>> 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.htmlbelong
> >     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
> >
> >
>
>