Return-Path: 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 ; 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 ; 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 ; 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 ; 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> <5358B8BC.8000508@gmx.net> <53590810.8000503@gmx.net> <4E1F6AAD24975D4BA5B16804296739439A1960AA@TK5EX14MBXC288.redmond.corp.microsoft.com> <535E160E.3010106@gmx.net> From: Brian Campbell Date: Mon, 28 Apr 2014 12:41:07 -0600 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e014954be54e40f04f81eaa12 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/oQQMGdUjI7SRiCm3yF4ySGkKUDQ Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 18:41:44 -0000 --089e014954be54e40f04f81eaa12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 t= o > > > > "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.1= to > > > > "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 i= n > > 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 identit= y > > 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 > > wrote: > > > > Agreed. > > > > On Apr 25, 2014, at 3:07 PM, Mike Jones > > wrote: > > > >> I agree. We=E2=80=99d already discussed this pretty extensively a= nd > >> reached the conclusion that always requiring both an issuer and a > >> subject both kept the specs simpler and was likely to improve > >> interoperability.____ > >> > >> It=E2=80=99s entirely up to the application profile what the conte= nts of > >> the issuer and the subject fields are and so I don=E2=80=99t think= we need > >> to further specify their contents beyond what=E2=80=99s 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 > >> *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 > >> > > >> 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 t= he > >> 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 acces= s > >> 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 identifie= s > 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 a= n > >> 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 tex= t? > >> > > >> > > >> > 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 > >> >____ > >> > >> ____ > >> > >> >>> 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, o= r > 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 follow= s: > >> > > > >> > > " > >> > > 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, o= r > 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 > >> >> > >> > >> > >> > >> > > https://www.ietf.org/mailman/listinfo/oauth > >> > > > >> > > > >> > > >> >____ > >> > >> __ __ > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > --089e014954be54e40f04f81eaa12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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(is= h).






On Mon, Apr 28, 2014 at 2:49 AM, Hannes Tschofenig <= ;hannes.tsch= ofenig@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 h= elps
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-a= ssertions-15#section-5.2 to
>
> "The assertion MUST contain a Subject. The Subject typically iden= tifies
> an authorized accessor for which the access token is being requested > (i.e. the resource owner, or an authorized delegate) but, in some case= s,
> 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.1 to
>
> "When a client is accessing resources on behalf of an anonymous u= ser, a
> mutually agreed upon Subject identifier indicating anonymity is used.<= br> > The Subject value might be an agreed upon static value indicating an > anonymous user or an opaque persistent or transient pseudonym for the<= br> > 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 id= entity
> is included, yet all the data needed to issue an access token is prese= nt."
>
> 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-s= aml2-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 th= e WG?
>
>
> On Fri, Apr 25, 2014 at 1:08 PM, John Bradley <ve7jtb@ve7jtb.com
> <mailto:ve7jtb@ve7jtb.com>> wrote:
>
> =C2=A0 =C2=A0 Agreed.
>
> =C2=A0 =C2=A0 On Apr 25, 2014, at 3:07 PM, Mike Jones <Michael.Jones@microsoft.com
> =C2=A0 =C2=A0 <mailto:Michael.Jones@microsoft.com>> wrote:
>
>> =C2=A0 =C2=A0 I agree. =C2=A0We=E2=80=99d already discussed this p= retty extensively and
>> =C2=A0 =C2=A0 reached the conclusion that always requiring both an= issuer and a
>> =C2=A0 =C2=A0 subject both kept the specs simpler and was likely t= o improve
>> =C2=A0 =C2=A0 interoperability.____
>>
>> =C2=A0 =C2=A0 It=E2=80=99s entirely up to the application profile = what the contents of
>> =C2=A0 =C2=A0 the issuer and the subject fields are and so I don= =E2=80=99t think we need
>> =C2=A0 =C2=A0 to further specify their contents beyond what=E2=80= =99s already in the
>> =C2=A0 =C2=A0 specs.____
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 --
>> =C2=A0 =C2=A0 Mike____
>>
>> =C2=A0 =C2=A0 *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian
>> =C2=A0 =C2=A0 Campbell
>> =C2=A0 =C2=A0 *Sent:* Friday, April 25, 2014 10:17 AM
>> =C2=A0 =C2=A0 *To:* Hannes Tschofenig
>> =C2=A0 =C2=A0 *Cc:* oauth@ietf.o= rg <mailto:oauth@ietf.org><= br> >> =C2=A0 =C2=A0 *Subject:* Re: [OAUTH-WG] draft-ietf-oauth-jwt-beare= r-08 & subject
>> =C2=A0 =C2=A0 issue____
>> =C2=A0 =C2=A0 __ __
>>
>> =C2=A0 =C2=A0 I believe, from the thread referenced earlier and pr= ior discussion
>> =C2=A0 =C2=A0 and draft text, that the WG has reached (rough) cons= ensus to
>> =C2=A0 =C2=A0 require the subject claim. So text that says "S= ubject element MUST
>> =C2=A0 =C2=A0 NOT be included" isn't workable.____<= br>
>>
>> =C2=A0 =C2=A0 It seems what's needed here is some better expla= nation of how, in
>> =C2=A0 =C2=A0 cases that need it, the value of the subject can be = populated
>> =C2=A0 =C2=A0 without using a PII type value. A simple static valu= e like
>> =C2=A0 =C2=A0 "ANONYMOUS-SUBJECT" could be used. Or, mor= e likely, some kind of
>> =C2=A0 =C2=A0 pairwise persistent pseudonymous identifier would be= utilized,
>> =C2=A0 =C2=A0 which would not directly identify the subject but wo= uld allow the
>> =C2=A0 =C2=A0 relying party to recognize the same subject on subse= quent
>> =C2=A0 =C2=A0 transactions. A transient pseudonym might also be ap= propriate in
>> =C2=A0 =C2=A0 some cases. And any of those approaches could be use= d with or
>> =C2=A0 =C2=A0 without additional claims (like age > 18 or membe= rship in some
>> =C2=A0 =C2=A0 group) that get used to make an authorization = decision. ____
>>
>> =C2=A0 =C2=A0 I wasn't sure exactly how to articulate all that= in text for the
>> =C2=A0 =C2=A0 draft(s) but that's more of what I was asking fo= r when I asked if
>> =C2=A0 =C2=A0 you could propose some text.____
>>
>>
>>
>>
>> =C2=A0 =C2=A0 ____
>>
>> =C2=A0 =C2=A0 __ __
>>
>> =C2=A0 =C2=A0 On Thu, Apr 24, 2014 at 6:48 AM, Hannes Tschofenig
>> =C2=A0 =C2=A0 <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>>
>> =C2=A0 =C2=A0 wrote:____
>> =C2=A0 =C2=A0 Hi Brian,
>>
>> =C2=A0 =C2=A0 Thanks for pointing to the assertion framework docum= ent.
>> =C2=A0 =C2=A0 Re-reading the
>> =C2=A0 =C2=A0 text it appears that we have listed the case that in= Section 6.3.1 but
>> =C2=A0 =C2=A0 have forgotten to cover it elsewhere in the document= .
>>
>>
>> =C2=A0 =C2=A0 In Section 6.3.1 we say:
>>
>> =C2=A0 =C2=A0 "
>>
>> =C2=A0 =C2=A0 6.3.1. =C2=A0Client Acting on Behalf of an Anonymous= User
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0When a client is accessing resources on= behalf of an anonymous
>> =C2=A0 =C2=A0 user,
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0the Subject indicates to the Authorizat= ion Server that the
>> =C2=A0 =C2=A0 client is
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0acting on-behalf of an anonymous user a= s defined by the
>> =C2=A0 =C2=A0 Authorization
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0Server. =C2=A0It is implied that author= ization is based upon additional
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0criteria, such as additional attributes= or claims provided in the
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0assertion. =C2=A0For example, a client = may present an assertion from a
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0trusted issuer asserting that the beare= r is over 18 via an included
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0claim.
>>
>> =C2=A0 =C2=A0 *****
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 In this case, no additional informatio= n about the user's
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0identity is included, yet all the data = needed to issue an access
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0token is present.
>> =C2=A0 =C2=A0 *****
>> =C2=A0 =C2=A0 "
>> =C2=A0 =C2=A0 (I marked the relevant part with '***')
>>
>>
>> =C2=A0 =C2=A0 In Section 5.2, however, we say:
>>
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0o =C2=A0The assertion MUST contain a Su= bject. =C2=A0The Subject identifies an
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 authorized accessor for which t= he access token is being
>> =C2=A0 =C2=A0 requested
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (typically the resource owner, = or an authorized delegate). =C2=A0When
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the client is acting on behalf = of itself, the Subject MUST
>> =C2=A0 =C2=A0 be the
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 value of the client's "= ;client_id".
>>
>>
>> =C2=A0 =C2=A0 What we should have done in Section 5.2 is to expand= the cases inline
>> =C2=A0 =C2=A0 with what we have written in Section 6.
>>
>> =C2=A0 =C2=A0 Here is my proposed text:
>>
>> =C2=A0 =C2=A0 "
>> =C2=A0 =C2=A0 o =C2=A0The assertion MUST contain a Subject. =C2=A0= The Subject identifies an
>> =C2=A0 =C2=A0 authorized accessor for which the access= token is being requested____
>>
>> =C2=A0 =C2=A0 (typically the resource owner, or an authorized dele= gate).
>>
>> =C2=A0 =C2=A0 ____
>>
>> =C2=A0 =C2=A0 When the client is acting on behalf of itself, as de= scribed in Section
>> =C2=A0 =C2=A0 6.1 and Section 6.2, the Subject MUST be the value o= f the client's
>> =C2=A0 =C2=A0 "client_id".
>>
>> =C2=A0 =C2=A0 When the client is acting on behalf of an user, as d= escribed in
>> =C2=A0 =C2=A0 Section
>> =C2=A0 =C2=A0 6.3, the Subject element MUST be included in the ass= ertion and
>> =C2=A0 =C2=A0 identifies an authorized accessor for which the acce= ss token is being
>> =C2=A0 =C2=A0 requested.
>>
>> =C2=A0 =C2=A0 When the client is acting on behalf of an anonymous = user, as described
>> =C2=A0 =C2=A0 in Section 6.3.1, the Subject element MUST NOT be in= cluded in the
>> =C2=A0 =C2=A0 assertion. Other elements within the assertion will,= however, provide
>> =C2=A0 =C2=A0 enough information for the authorization server to m= ake an
>> =C2=A0 =C2=A0 authorization
>> =C2=A0 =C2=A0 decision.
>> =C2=A0 =C2=A0 "
>>
>> =C2=A0 =C2=A0 Does this make sense to you?
>>
>> =C2=A0 =C2=A0 Ciao
>> =C2=A0 =C2=A0 Hannes____
>>
>>
>> =C2=A0 =C2=A0 On 04/24/2014 02:30 PM, Brian Campbell wrote:
>> =C2=A0 =C2=A0 > There is some discussion of that case in the as= sertion framework
>> =C2=A0 =C2=A0 > document at
>> =C2=A0 =C2=A0 > http://tools.ietf.or= g/html/draft-ietf-oauth-assertions-15#section-6.3.1
>> =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > Do you feel that more is needed? If so, can you= propose some text?
>> =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > On Thu, Apr 24, 2014 at 1:09 AM, Hannes T= schofenig____
>> =C2=A0 =C2=A0 > <hannes.tschofenig@gmx.net
>> =C2=A0 =C2=A0 <mailto:hannes.tschofenig@gmx.net> <mailto:hannes.tschofenig@gmx.net
>> =C2=A0 =C2=A0 <mailto:hannes.tschofenig@gmx.net>>> wrote:
>> =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 Hi Brian,
>> =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 I read through the thread and the= Google case is a bit
>> =C2=A0 =C2=A0 different since
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 they are using the client authent= ication part of the JWT
>> =C2=A0 =C2=A0 bearer spec.
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 There I don't see the privacy= concerns either.
>> =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 I am, however, focused on the aut= horization grant where the
>> =C2=A0 =C2=A0 subject is
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 in most cases the resource owner.=
>> =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 It is possible to put garbage int= o the subject element when
>> =C2=A0 =C2=A0 privacy
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 protection is needed for the reso= urce owner case but that
>> =C2=A0 =C2=A0 would need to
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 be described in the document; cur= rently it is not there.
>> =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 Ciao
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 Hannes
>> =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 On 04/24/2014 12:37 AM, Brian Cam= pbell wrote:
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > That thread that Antonio sta= rted which you reference went
>> =C2=A0 =C2=A0 on for some
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > time
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 (http://www.ietf.org/mail-a= rchive/web/oauth/current/threads.html#12520)
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > and seems to have reached co= nsensus that the spec didn't need
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 normative
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > change and that such privacy= cases or other cases which didn't
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > explicitly need a subject id= entifier would be more
>> =C2=A0 =C2=A0 appropriately dealt
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > with in application logic: >> =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > http://www.ietf.org/mail-ar= chive/web/oauth/current/msg12538.html
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > On Wed, Apr 23, 2014 at 2:39= AM, Hannes Tschofenig
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > <hannes.tschofenig@gmx.net
>> =C2=A0 =C2=A0 <mailto:hannes.tschofenig@gmx.net> <mailto:hannes.tschofenig@gmx.net
>> =C2=A0 =C2=A0 <mailto:hannes.tschofenig@gmx.net>>____
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 <mailto:hannes.tschofenig@gmx.net
>> =C2=A0 =C2=A0 <mailto:hannes.tschofenig@gmx.net>____
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 <mailto= :hannes.tschofenig@gmx.net=
>> =C2=A0 =C2=A0 <mailto:hannes.tschofenig@gmx.net>>>> wrote:
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 Hi all,
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 in preparing t= he shepherd write-up for
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 draft-ietf-oauth-jwt-bearer-08 I<= br> >> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 had to review = our recent email conversations and the issue
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 raised by
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 Antonio in
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/mail-= archive/web/oauth/current/msg12520.html belong
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 to it.
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 The issue was = that Section 3 of
>> =C2=A0 =C2=A0 draft-ietf-oauth-jwt-bearer-08
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 says:
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 "
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A02= . =C2=A0 The JWT MUST contain a "sub" (subject) claim
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 identifying the
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 principal that is the subject of the JWT. =C2=A0Two
>> =C2=A0 =C2=A0 cases
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 need to be
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 differentiated:
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 A. =C2=A0For the authorization grant, the subject
>> =C2=A0 =C2=A0 SHOULD
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 identify an
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 authorized accessor for whom the access
>> =C2=A0 =C2=A0 token is being
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 requested (typically the resource owner, or an<= br> >> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 authorized
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 delegate).
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 B. =C2=A0For client authentication, the subject
>> =C2=A0 =C2=A0 MUST be the
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 "client_id" of the OAuth client.
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 "
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 Antonio pointe= d to the current Google API to
>> =C2=A0 =C2=A0 illustrate that
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 the subject
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 is not always = needed. Here is the Google API
>> =C2=A0 =C2=A0 documentation:
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 =C2=A0 https://developers.google= .com/accounts/docs/OAuth2ServiceAccount
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 The Google API= used the client authentication part (rather
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 than the
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 authorization = grant), in my understanding.
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 I still believ= e that the subject field has to be
>> =C2=A0 =C2=A0 included for
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 client
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 authentication= but I am not so sure anymore about the
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 authorization
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 grant since I = could very well imagine cases where the
>> =C2=A0 =C2=A0 subject
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 is not
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 needed for aut= horization decisions but also for
>> =C2=A0 =C2=A0 privacy reasons.
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 I would theref= ore suggest to change the text as follows:
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 "
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A02= . =C2=A0 The JWT contains a "sub" (subject) claim
>> =C2=A0 =C2=A0 identifying the
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 principal that is the subject of the JWT. =C2=A0Two
>> =C2=A0 =C2=A0 cases
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 need to be
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 differentiated:
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 A. =C2=A0For the authorization grant, the subject
>> =C2=A0 =C2=A0 claim MAY
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 be included. If it is included it MUST
>> =C2=A0 =C2=A0 identify the
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 authorized accessor for whom the access
>> =C2=A0 =C2=A0 token is being
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 requested (typically the resource owner, or an<= br> >> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 authorized
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 delegate). Reasons for not including the
>> =C2=A0 =C2=A0 subject claim
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 in the JWT are identity hiding (i.e., privacy >> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 protection
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the identifier of the subject) and
>> =C2=A0 =C2=A0 cases where
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 the identifier of the subject is
>> =C2=A0 =C2=A0 irrelevant for making
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 an authorization decision by the resource
>> =C2=A0 =C2=A0 server.
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 B. =C2=A0For client authentication, the subject
>> =C2=A0 =C2=A0 MUST be the
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 included in the JWT and the value MUST be
>> =C2=A0 =C2=A0 populated
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 with the "client_id" of the OAuth cli= ent.
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 "
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 What do you gu= ys think?
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 Ciao
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 Hannes
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 ______________= _________________________________
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 OA= uth mailing list____
>>
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 OAuth@ietf.org
>> =C2=A0 =C2=A0 <mailto:OAuth@i= etf.org> <mailto:OAuth@ietf.org=
>> =C2=A0 =C2=A0 <mailto:O= Auth@ietf.org>> <mailto:OAut= h@ietf.org
>> =C2=A0 =C2=A0 <mailto:OAuth@i= etf.org>
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>>
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 https://www.iet= f.org/mailman/listinfo/oauth
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 >
>> =C2=A0 =C2=A0 >____
>>
>> =C2=A0 =C2=A0 __ __
>> =C2=A0 =C2=A0 ____________________________________= ___________
>> =C2=A0 =C2=A0 OAuth mailing list
>> =C2=A0 =C2=A0 OAuth@ietf.org= <mailto:OAuth@ietf.org>
>> =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/oauth=
>
>


--089e014954be54e40f04f81eaa12--