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

Brian Campbell <bcampbell@pingidentity.com> Mon, 28 April 2014 18:41 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 ED06A1A0792 for <oauth@ietfa.amsl.com>; Mon, 28 Apr 2014 11:41:43 -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 zsWbrHlhnSyJ for <oauth@ietfa.amsl.com>; Mon, 28 Apr 2014 11:41:40 -0700 (PDT)
Received: from na6sys009bog007.obsmtp.com (na6sys009bog007.obsmtp.com [74.125.150.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5DE1A04F1 for <oauth@ietf.org>; Mon, 28 Apr 2014 11:41:39 -0700 (PDT)
Received: from mail-ie0-f179.google.com ([209.85.223.179]) (using TLSv1) by na6sys009bob007.postini.com ([74.125.148.12]) with SMTP ID DSNKU16g4qU8vpI3snabwLuBdzT3BlT1KfxG@postini.com; Mon, 28 Apr 2014 11:41:38 PDT
Received: by mail-ie0-f179.google.com with SMTP id lx4so6975241iec.38 for <oauth@ietf.org>; Mon, 28 Apr 2014 11:41:37 -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=tq1qAmJ5+xOq+MzJUqZR4g2h9gsSoHZT3Zn81kPmlO4=; b=jDUSpHukd11KGfv3lxS5SA3loAczslWInTfixOIYE+abZzlwVpW/WK0KGa3fjT1kgg jzRtS0fmxPSXknDs3S3rJsAz2chuwpYtdO/R+Z1gnknw2XPMz8PesznGU2nvXAIIuLwi cWzpQ9jIgEbrVV2L50odWXMQzpdzBDSh/QcG1om1055CyOGFh39FBM43U5jx3p5Ah7UH xOr77od0W3D0kxIr8CznXonqOGo1IaUqSVGAX21SkfTmSV35Yw1I7KX4j8zBn1TzLufz VgOLNsRfDHy0JOEZnQal2dRaUVHfFcUiG/VBJlwbf+CaurGIdHAi9HvahhZrSprhE4Oc zcww==
X-Gm-Message-State: ALoCoQkdK5nmrmEnaCqyeTeDUIm7jVWqa5eOidKV1MCzE5FueRIogsSJ6XECd8tzrc694i9jyuQd5o/wryG2eMdFUY+thuagg++Vtw/ojo+8jvCK3vpHDZklJYAr4RZPy0omZgM2pInA
X-Received: by 10.50.153.49 with SMTP id vd17mr26594388igb.40.1398710497371; Mon, 28 Apr 2014 11:41:37 -0700 (PDT)
X-Received: by 10.50.153.49 with SMTP id vd17mr26594367igb.40.1398710497205; Mon, 28 Apr 2014 11:41:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.240.201 with HTTP; Mon, 28 Apr 2014 11:41:07 -0700 (PDT)
In-Reply-To: <535E160E.3010106@gmx.net>
References: <53577C41.2090606@gmx.net> <CA+k3eCSmVo__OBn7vMoSZ2POeFLUS11y+BNOPTX5b=5C_OpfBg@mail.gmail.com> <5358B8BC.8000508@gmx.net> <CA+k3eCSCtSb42pqz8qE4MQbfXzLQFr9bEAcNm0bgJ24WRL4C4Q@mail.gmail.com> <53590810.8000503@gmx.net> <CA+k3eCRvukGj-oZ214JNdaAENobrdcanxPxZiAUZ9B529Zsd5A@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439A1960AA@TK5EX14MBXC288.redmond.corp.microsoft.com> <A83036B3-E093-41C6-A212-B5797E536326@ve7jtb.com> <CA+k3eCToMDJv4KfapoG=9gSHrtzKT5E8L4OFSJMjQZWBO4Q84g@mail.gmail.com> <535E160E.3010106@gmx.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 28 Apr 2014 12:41:07 -0600
Message-ID: <CA+k3eCSRGj_t8PD46mjyC0Q4PrQz0jvyQZP1i9HX3HmCKZ5CHQ@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary=089e014954be54e40f04f81eaa12
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/oQQMGdUjI7SRiCm3yF4ySGkKUDQ
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: Mon, 28 Apr 2014 18:41:44 -0000

Thanks Hannes,

I'll update that text to reference RFC 6973 and also to indicate a specific
value which could be used for the anonymous user. And I'll publish new
drafts here soon(ish).






On Mon, Apr 28, 2014 at 2:49 AM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Hi all,
>
> your text proposal sounds reasonable and it might, as suggested,
> indicate what value to put in there for the anonymous user (such as
> 'anonymous'). Saying explicitly what implementers should be doing helps
> interoperability.
>
> Mentioning the pseudonym is also a good idea since in some cases
> anonymity can be too strong and pseudonymity is what is desired. For the
> terminology you could reference RFC 6973.
>
> Ciao
> Hannes
>
> PS: A note to various folks in this email thread: We have not discussed
> this issue before. As I mentioned in my original email we had only
> discussed a related issue regarding client authentication. Antonio's
> email lead me to think about the authorization grant, which is obviously
> a different story (which only happens to be in the same document because
> of the document structure we came up with).
>
> On 04/25/2014 09:57 PM, Brian Campbell wrote:
> > I absolutely agree with always requiring both issuer and subject and
> > that doing so keeps the specs simpler and is likely to improve
> > interoperability.
> >
> > However, without changing that, perhaps some of the text in the
> > document(s) could be improved a bit. Here's a rough proposal:
> >
> > Change the text of the second bullet in
> > http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-5.2 to
> >
> > "The assertion MUST contain a Subject. The Subject typically identifies
> > an authorized accessor for which the access token is being requested
> > (i.e. the resource owner, or an authorized delegate) but, in some cases,
> > may be a pseudonym or other value denoting an anonymous user. When the
> > client is acting on behalf of itself, the Subject MUST be the value of
> > the client's client_id."
> >
> > And also change
> > http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-6.3.1to
> >
> > "When a client is accessing resources on behalf of an anonymous user, a
> > mutually agreed upon Subject identifier indicating anonymity is used.
> > The Subject value might be an agreed upon static value indicating an
> > anonymous user or an opaque persistent or transient pseudonym for the
> > user may also be utilized. The authorization may be 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."
> >
> > And maybe also change the subject text in SAML and JWT (item #2 in
> > http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-08#section-3 and
> > http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-19#section-3)
> > to read a little more like the new proposed text above for section 5.2
> > of the Assertion Framework draft.
> >
> > Would that sit any better with you, Hannes? Thoughts from others in the
> WG?
> >
> >
> > On Fri, Apr 25, 2014 at 1:08 PM, John Bradley <ve7jtb@ve7jtb.com
> > <mailto:ve7jtb@ve7jtb.com>> wrote:
> >
> >     Agreed.
> >
> >     On Apr 25, 2014, at 3:07 PM, Mike Jones <Michael.Jones@microsoft.com
> >     <mailto:Michael.Jones@microsoft.com>> wrote:
> >
> >>     I agree.  We’d already discussed this pretty extensively and
> >>     reached the conclusion that always requiring both an issuer and a
> >>     subject both kept the specs simpler and was likely to improve
> >>     interoperability.____
> >>
> >>     It’s entirely up to the application profile what the contents of
> >>     the issuer and the subject fields are and so I don’t think we need
> >>     to further specify their contents beyond what’s already in the
> >>     specs.____
> >>
> >>                                                                 --
> >>     Mike____
> >>
> >>     *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian
> >>     Campbell
> >>     *Sent:* Friday, April 25, 2014 10:17 AM
> >>     *To:* Hannes Tschofenig
> >>     *Cc:* oauth@ietf.org <mailto:oauth@ietf.org>
> >>     *Subject:* Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject
> >>     issue____
> >>     __ __
> >>
> >>     I believe, from the thread referenced earlier and prior discussion
> >>     and draft text, that the WG has reached (rough) consensus to
> >>     require the subject claim. So text that says "Subject element MUST
> >>     NOT be included" isn't workable.____
> >>
> >>     It seems what's needed here is some better explanation of how, in
> >>     cases that need it, the value of the subject can be populated
> >>     without using a PII type value. A simple static value like
> >>     "ANONYMOUS-SUBJECT" could be used. Or, more likely, some kind of
> >>     pairwise persistent pseudonymous identifier would be utilized,
> >>     which would not directly identify the subject but would allow the
> >>     relying party to recognize the same subject on subsequent
> >>     transactions. A transient pseudonym might also be appropriate in
> >>     some cases. And any of those approaches could be used with or
> >>     without additional claims (like age > 18 or membership in some
> >>     group) that get used to make an authorization decision. ____
> >>
> >>     I wasn't sure exactly how to articulate all that in text for the
> >>     draft(s) but that's more of what I was asking for when I asked if
> >>     you could propose some text.____
> >>
> >>
> >>
> >>
> >>     ____
> >>
> >>     __ __
> >>
> >>     On Thu, Apr 24, 2014 at 6:48 AM, Hannes Tschofenig
> >>     <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>>
> >>     wrote:____
> >>     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> <mailto:
> 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>>____
> >>     >     <mailto: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.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> <mailto:OAuth@ietf.org
> >>     <mailto:OAuth@ietf.org>> <mailto:OAuth@ietf.org
> >>     <mailto:OAuth@ietf.org>
> >>     >     <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>>
> >>     >     >     https://www.ietf.org/mailman/listinfo/oauth
> >>     >     >
> >>     >     >
> >>     >
> >>     >____
> >>
> >>     __ __
> >>     _______________________________________________
> >>     OAuth mailing list
> >>     OAuth@ietf.org <mailto:OAuth@ietf.org>
> >>     https://www.ietf.org/mailman/listinfo/oauth
> >
> >
>
>