Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
George Fletcher <gffletch@aol.com> Mon, 12 March 2012 14:08 UTC
Return-Path: <gffletch@aol.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC12C21F85AF for <oauth@ietfa.amsl.com>; Mon, 12 Mar 2012 07:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.87
X-Spam-Level:
X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CheiOcIaST0F for <oauth@ietfa.amsl.com>; Mon, 12 Mar 2012 07:08:45 -0700 (PDT)
Received: from imr-db03.mx.aol.com (imr-db03.mx.aol.com [205.188.91.97]) by ietfa.amsl.com (Postfix) with ESMTP id ADF0921F8567 for <oauth@ietf.org>; Mon, 12 Mar 2012 07:08:43 -0700 (PDT)
Received: from mtaout-ma05.r1000.mx.aol.com (mtaout-ma05.r1000.mx.aol.com [172.29.41.5]) by imr-db03.mx.aol.com (8.14.1/8.14.1) with ESMTP id q2CE8WLI032247; Mon, 12 Mar 2012 10:08:32 -0400
Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 679B1E000141; Mon, 12 Mar 2012 10:08:32 -0400 (EDT)
Message-ID: <4F5E0360.8060700@aol.com>
Date: Mon, 12 Mar 2012 10:08:32 -0400
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Richer, Justin P." <jricher@mitre.org>
References: <4E1F6AAD24975D4BA5B168042967394366402261@TK5EX14MBXC284.redmond.corp.microsoft.com> <6C7AC84B-F4F3-4069-9144-65B193D0F882@ve7jtb.com>, <CA+k3eCSoOumeULRYynRDrQFksf+h7iczhMqp33-GUDvGL15tAQ@mail.gmail.com> <B33BFB58CCC8BE4998958016839DE27E0E1D8D@IMCMBX01.MITRE.ORG>
In-Reply-To: <B33BFB58CCC8BE4998958016839DE27E0E1D8D@IMCMBX01.MITRE.ORG>
Content-Type: multipart/alternative; boundary="------------090900070108010405010804"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1331561312; bh=gqkI6B4kHf+M1wxFdWaU3GIPBYHaVfZfY/eOFVURmYE=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=YQjLiUSet73aV2chK9NJL1KcwTnDqN0xfqKnnhFIRrWXuA1ZopgDCchZdDv5nM9KP Jo/5JS4Y7r2TVAiXI0QF/TUdm7/F57kVE5aWhTXN0kS0AyxcoPs8W9LXjaWcnrlEZX sf+hrwb95g6h0zBVypOjbRVpR02/HP9R4AIVyu6A=
X-AOL-SCOLL-SCORE: 0:2:509327136:93952408
X-AOL-SCOLL-URL_COUNT: 0
x-aol-sid: 3039ac1d29054f5e03602060
X-AOL-IP: 10.181.186.254
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Mar 2012 14:08:48 -0000
+1 On 3/11/12 12:45 PM, Richer, Justin P. wrote: > +1 > ------------------------------------------------------------------------ > *From:* oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of > Brian Campbell [bcampbell@pingidentity.com] > *Sent:* Sunday, March 11, 2012 9:50 AM > *To:* John Bradley > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] question about the b64token syntax in > draft-ietf-oauth-v2-bearer > > +1 > > On Mar 11, 2012 7:08 AM, "John Bradley" <ve7jtb@ve7jtb.com > <mailto:ve7jtb@ve7jtb.com>> wrote: > > +1 > > Sent from my iPhone > > On 2012-03-10, at 12:49 PM, Mike Jones > <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> > wrote: > >> I plan to make the change to the example access token value to >> mF_9.B5f-4.1JqMbefore Monday’s submission deadline, per the >> requests for b64token syntax clarification. I’m also considering >> adding an access token response example, pre the requests in this >> thread. I would propose adding the following new text for this >> in a new Section 4 (before the current Security Considerations). >> This is largely parallel to what is done in Section 5.1 of the >> MAC spec. >> >> *4. Example Access Token Response* >> >> Typically a bearer token is returned to the client as part of an >> OAuth 2.0 [I-D.ietf-oauth-v2] access token response. An example >> of such as response is: >> >> HTTP/1.1 200 OK >> >> Content-Type: application/json;charset=UTF-8 >> >> Cache-Control: no-store >> >> Pragma: no-cache >> >> { >> >> "access_token":"mF_9.B5f-4.1JqM", >> >> "token_type":"Bearer", >> >> "expires_in":3600, >> >> "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" >> >> } >> >> Please send either +1s or objections to this text by mid-day >> Monday. Unless I receive several +1s, to be conservative at this >> point, I will not be including it in Monday’s draft. >> >> -- Mike >> >> *From:*oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org> >> [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>] >> *On Behalf Of *Paul Madsen >> *Sent:* Wednesday, March 07, 2012 1:34 PM >> *To:* Brian Campbell >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] question about the b64token syntax in >> draft-ietf-oauth-v2-bearer >> >> +1 >> >> On 3/7/12 4:08 PM, Brian Campbell wrote: >> >> Yeah, it is case insensitive. I just went with the upper case B >> because that's how it was written in §5.1.1 of >> draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually >> defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**. >> Either one would be fine. >> >> I agree that an example response from the token endpoint would be >> worthwhile. Something like the following might help tie together with >> the Authorization header example (proposed earlier). It could maybe be >> worked in near the top of §2? >> >> HTTP/1.1 200 OK >> Content-Type: application/json;charset=UTF-8 >> Cache-Control: no-store >> Pragma: no-cache >> >> { >> "access_token":"vF_9.5dCf-t4.qbcmT_k1b", >> "token_type":"example", >> "expires_in":3600, >> "refresh_token":"stGzv3xOdkF0X35Qp2TlKWIA", >> } >> >> It'd probably make sense to change the examples in the body §2.2*** >> and query §2.3**** to use the same access token value too. >> >> >> *http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1 >> **http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1 >> ***http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2 >> ****http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3 >> >> >> On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer<jricher@mitre.org> <mailto:jricher@mitre.org> wrote: >> >> Makes sense to me, except that I think the token_type value is typically >> >> lowercase "bearer", though it's defined to be case insensitive in >> >> Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value of >> >> this field for the Bearer token type ever got defined anywhere. Section 7.1 >> >> references the bearer spec as defining the value of the "token_type" >> >> parameter, and passes its example as if by reference. Would be worthwhile >> >> giving an example of a token endpoint response, such as what's found in >> >> OAuth-v2-23 section 5.1. >> >> >> >> -- Justin >> >> >> >> >> >> On 03/07/2012 12:16 PM, Brian Campbell wrote: >> >> >> >> I'd like to propose the following changes and additions, derived >> >> largely from Bill and James suggestions, to >> >> draft-ietf-oauth-v2-bearer-17. These changes have no normative impact >> >> and only aim to add additional clarity and explanation the workings >> >> and implications of the current spec. I'm definitely open to changes >> >> or improvements in the wording here (not my strong suit by any means) >> >> but I think it's important that these general ideas be conveyed in the >> >> draft. >> >> >> >> >> >> ==> Insert the following text at the beginning of §2: >> >> >> >> To make a protected resource request, the client must be in possession >> >> of a valid bearer token. Typically a bearer token is returned to the >> >> client as part of an access token response as defined in OAuth 2.0 >> >> [I-D.ietf-oauth-v2]. When the "token_type" parameter of the access >> >> token response is "Bearer", the string value of the "access_token" >> >> parameter becomes the bearer access token used to make protected >> >> resource requests. >> >> >> >> ==> Change the value of the token in the Authorization header example to >> >> this: >> >> >> >> Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b >> >> >> >> ==> Insert the following text before the last paragraph of §2.1: >> >> >> >> Note that the name b64token does not imply base64 encoding but rather >> >> is the name for an ABNF syntax definition from HTTP/1.1, Part 7 >> >> [I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token" >> >> string value from an access token response MUST match the b64token >> >> ABNF so it can be used with the Bearer HTTP scheme. >> >> >> >> >> >> Thanks, >> >> Brian >> >> >> >> >> >> >> >> >> >> On Tue, Mar 6, 2012 at 11:45 AM, William Mills<wmills@yahoo-inc.com> <mailto:wmills@yahoo-inc.com> >> >> wrote: >> >> >> >> Yeah, something as simple as, "Note that the name 'b64token' does not >> >> imply >> >> base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would >> >> do >> >> it. >> >> >> >> -bill >> >> >> >> ________________________________ >> >> From: Brian Campbell<bcampbell@pingidentity.com> <mailto:bcampbell@pingidentity.com> >> >> To: Mike Jones<Michael.Jones@microsoft.com> <mailto:Michael.Jones@microsoft.com> >> >> Cc: oauth<oauth@ietf.org> <mailto:oauth@ietf.org> >> >> Sent: Tuesday, March 6, 2012 8:23 AM >> >> >> >> Subject: Re: [OAUTH-WG] question about the b64token syntax in >> >> draft-ietf-oauth-v2-bearer >> >> >> >> Thanks Mike, I think changing the example would be helpful. >> >> >> >> However I think that including some text along the lines of what James >> >> suggested would also be very valuable. I agree that the connection >> >> between OAuth and Bearer could and should be made more explicit. And >> >> that the implications of the b64token syntax, particularly on what AS >> >> can use to construct ATs, could/should be made more clear. >> >> >> >> I can propose some specific text (building on James') if others in the WG >> >> agree? >> >> >> >> >> >> On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones<Michael.Jones@microsoft.com> <mailto:Michael.Jones@microsoft.com> >> >> wrote: >> >> >> >> I'm fine with changing the example to make it clearer that b64token >> >> allows >> >> a wider range of characters than just those legal for base64 and >> >> base64url >> >> encodings of data values. >> >> >> >> I'll add it to my to-do list for any additional edits for the Bearer >> >> spec. >> >> >> >> -- Mike >> >> >> >> -----Original Message----- >> >> From:mailto:oauth-bounces@ietf.org] On Behalf >> >> Of >> >> Manger, James H >> >> Sent: Monday, March 05, 2012 3:33 PM >> >> To: Brian Campbell; oauth >> >> Subject: Re: [OAUTH-WG] question about the b64token syntax in >> >> draft-ietf-oauth-v2-bearer >> >> >> >> Brian, >> >> >> >> On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer >> >> Tokens"* I've encountered several people (including myself) who have >> >> made the assumption that the name b64token implies that some kind of >> >> base64 encoding/decoding on the access token is taking place between >> >> the client and RS. >> >> >> >> Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**, >> >> however, I see that b64token is just an ABNF syntax definition >> >> allowing for characters typically used in base64, base64url, etc.. So >> >> the b64token doesn't define any encoding or decoding but rather just >> >> defines what characters can be used in the part of the Authorization >> >> header that will contain the access token. >> >> >> >> Do I read this correctly? >> >> >> >> Yes. >> >> >> >> If so, I feel like some additional clarifying text in the Bearer >> >> Tokens draft might help avoid what is (based on my small sample) a >> >> common point of misunderstanding. >> >> >> >> Changing the example bearer token should be a simple way to avoid some >> >> confusion by showing that it does not have to be base64 encoding. How >> >> about >> >> changing: >> >> Authorization: Bearer vF9dft4qmT >> >> to >> >> Authorization: Bearer vF9.dft4.qmT >> >> >> >> The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't >> >> quite manage to be precise about how OAuth and Bearer connect. It could >> >> explicitly state that the string value of the "access_token" member of >> >> an >> >> access token response is the bearer token. The "access_token" string >> >> value >> >> (after unescaping any JSON-escapes) MUST match the b64token ABNF so it >> >> can >> >> be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 >> >> where >> >> the "Bearer" OAuth access token type is defined. >> >> >> >> >> >> Also, does the use of b64token implicitly limit the allowed characters >> >> that an AS can use to construct a bearer access token? >> >> >> >> Yes. >> >> >> >> >> >> *http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 >> >> ** >> >> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 >> >> >> >> -- >> >> James Manger >> >> _______________________________________________ >> >> OAuth mailing list >> >> 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 >> >> >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> 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 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Chief Architect AIM: gffletch Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. Home: gffletch@aol.com Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.com Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch
- [OAUTH-WG] question about the b64token syntax in … Brian Campbell
- Re: [OAUTH-WG] question about the b64token syntax… Manger, James H
- Re: [OAUTH-WG] question about the b64token syntax… Mike Jones
- Re: [OAUTH-WG] question about the b64token syntax… Brian Campbell
- Re: [OAUTH-WG] question about the b64token syntax… Paul Madsen
- Re: [OAUTH-WG] question about the b64token syntax… Justin Richer
- Re: [OAUTH-WG] question about the b64token syntax… William Mills
- Re: [OAUTH-WG] question about the b64token syntax… Brian Campbell
- Re: [OAUTH-WG] question about the b64token syntax… William Mills
- Re: [OAUTH-WG] question about the b64token syntax… Justin Richer
- Re: [OAUTH-WG] question about the b64token syntax… Brian Campbell
- Re: [OAUTH-WG] question about the b64token syntax… Paul Madsen
- Re: [OAUTH-WG] question about the b64token syntax… Mike Jones
- Re: [OAUTH-WG] question about the b64token syntax… Manger, James H
- Re: [OAUTH-WG] question about the b64token syntax… Paul Madsen
- Re: [OAUTH-WG] question about the b64token syntax… John Bradley
- Re: [OAUTH-WG] question about the b64token syntax… Brian Campbell
- Re: [OAUTH-WG] question about the b64token syntax… Richer, Justin P.
- Re: [OAUTH-WG] question about the b64token syntax… George Fletcher