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

Brian Campbell <bcampbell@pingidentity.com> Mon, 28 April 2014 22:02 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 6DDD81A7035 for <oauth@ietfa.amsl.com>; Mon, 28 Apr 2014 15:02:40 -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 NUh8HC5OP7vc for <oauth@ietfa.amsl.com>; Mon, 28 Apr 2014 15:02:34 -0700 (PDT)
Received: from na3sys009aog134.obsmtp.com (na3sys009aog134.obsmtp.com [74.125.149.83]) by ietfa.amsl.com (Postfix) with ESMTP id C19651A8837 for <oauth@ietf.org>; Mon, 28 Apr 2014 15:02:33 -0700 (PDT)
Received: from mail-ig0-f180.google.com ([209.85.213.180]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKU17P74si/FxDI2anXPv4tSIidxV7nplb@postini.com; Mon, 28 Apr 2014 15:02:33 PDT
Received: by mail-ig0-f180.google.com with SMTP id r2so246536igi.7 for <oauth@ietf.org>; Mon, 28 Apr 2014 15:02:22 -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=SdZp8POGL62o782SgzUXt9nKY73VKVjRf1bQuqGBcik=; b=gCw+c27HvzyEZotFxrQ/UnAf/UlWKYZ8O/LrfE0wNYAQNehWz1ONKe/MG+yXXqrL2x ij6Pq92KQpdE3JFibRYLz1Sn3TCWxjxnu4b//GtSC6KXEu+01vJEjdEIci8FlhsFAFkh ReJwTX/VlLWjJzOf9+7R9JCP4SNRTn3hzcJmvn7oRO5xsPcrqgmsvzAF8HB30PCdYTEf iDtL1wH+9jhKIYBLJ7uR85NKNNh4hzgicBwCcRgEDhOZdVy2QQVLzJyPmOVD5nZNhpMV eTQnjR/HbE8A4qcQ9APmmyWPev3flzdzQQc0UqqDe3/N8m1Jcyz7udx7IMEKIianaZVH 9vQw==
X-Gm-Message-State: ALoCoQksUs1RBjDN82njqJS7mIaBgUSjZA6Wc0WEihhHRajrP7iEz582ntq3qfdNXGZDDVjF0SLUcwclwYOT/eWxS28P4QU5yJhRjP7RBDHk6wA2pGkDUb97qHBsy1vPqEtY6YPUpq+C
X-Received: by 10.50.153.49 with SMTP id vd17mr27647449igb.40.1398722542671; Mon, 28 Apr 2014 15:02:22 -0700 (PDT)
X-Received: by 10.50.153.49 with SMTP id vd17mr27647435igb.40.1398722542554; Mon, 28 Apr 2014 15:02:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.240.201 with HTTP; Mon, 28 Apr 2014 15:01:52 -0700 (PDT)
In-Reply-To: <CA+k3eCSRGj_t8PD46mjyC0Q4PrQz0jvyQZP1i9HX3HmCKZ5CHQ@mail.gmail.com>
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> <CA+k3eCSRGj_t8PD46mjyC0Q4PrQz0jvyQZP1i9HX3HmCKZ5CHQ@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 28 Apr 2014 16:01:52 -0600
Message-ID: <CA+k3eCR_ZTBZR3SxDH2eeZYKqiA7kuPeBPg_cqPut2XrFAjvsg@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary=089e014954be49e4cd04f8217808
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ct7bAGcLTUGHo43c87iiGXdfbyU
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 22:02:41 -0000

And those new drafts have now been published:

http://tools.ietf.org/html/draft-ietf-oauth-assertions-16
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-09
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-20


On Mon, Apr 28, 2014 at 12:41 PM, Brian Campbell <bcampbell@pingidentity.com
> wrote:

> 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.2to
>> >
>> > "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
>> >
>> >
>>
>>
>