Re: [OAUTH-WG] Error Encoding: Conclusion
Mike Jones <Michael.Jones@microsoft.com> Thu, 31 May 2012 20:53 UTC
Return-Path: <Michael.Jones@microsoft.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 25AF411E8081 for <oauth@ietfa.amsl.com>; Thu, 31 May 2012 13:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.612
X-Spam-Level:
X-Spam-Status: No, score=-3.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 PbLL7OZMP5ni for <oauth@ietfa.amsl.com>; Thu, 31 May 2012 13:53:04 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1AD11E8080 for <oauth@ietf.org>; Thu, 31 May 2012 13:53:03 -0700 (PDT)
Received: from mail60-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 31 May 2012 20:52:33 +0000
Received: from mail60-am1 (localhost [127.0.0.1]) by mail60-am1-R.bigfish.com (Postfix) with ESMTP id 7172720496; Thu, 31 May 2012 20:52:33 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -43
X-BigFish: VS-43(zz9371I179cM14ffI542M1432N1418I98dK4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah)
Received-SPF: pass (mail60-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail60-am1 (localhost.localdomain [127.0.0.1]) by mail60-am1 (MessageSwitch) id 1338497550459697_12081; Thu, 31 May 2012 20:52:30 +0000 (UTC)
Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.244]) by mail60-am1.bigfish.com (Postfix) with ESMTP id 6E4A0A0046; Thu, 31 May 2012 20:52:30 +0000 (UTC)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 31 May 2012 20:52:28 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Thu, 31 May 2012 20:52:53 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Eran Hammer <eran@hueniverse.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>
Thread-Topic: [OAUTH-WG] Error Encoding: Conclusion
Thread-Index: AQHNORGtuzciwTXPbU2x0B3Abs7zkpbYRq5QgAA2y4CAAAHMgIAI6/dggALF+ICAAAlrAIAAHEsAgAAVMWA=
Date: Thu, 31 May 2012 20:52:52 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436652221D@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <FADC0EB3-75F7-45E8-93B8-A9C3A07E2E88@gmx.net> <4E1F6AAD24975D4BA5B168042967394366516960@TK5EX14MBXC284.redmond.corp.microsoft.com> <CAB_mRgMumU5qzEJF0KCWNCx+R4MAzVawiJGKj2YBpJFzrxkomQ@mail.gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20104B3A1@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B16804296739436651E440@TK5EX14MBXC284.redmond.corp.microsoft.com> <C306A031-C2F0-4912-8341-312DFF4973BD@gmx.net> <869336FE-0265-4982-B9DE-E2FAE06CD545@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA20105888A@P3PWEX2MB008.ex2.secureserver.net>
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20105888A@P3PWEX2MB008.ex2.secureserver.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.78]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Error Encoding: Conclusion
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: Thu, 31 May 2012 20:53:06 -0000
Actually, could you please publish before the ABNF is done so that I can publish a version of Bearer referencing the new text in Core, so it can be reviewed by the WG in parallel with the ABNF work happening? I think that was Hannes' intent in asking you to publish soon. Version numbers are cheap... Thanks, -- Mike -----Original Message----- From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, May 31, 2012 12:35 PM To: Hannes Tschofenig Cc: Mike Jones; oauth@ietf.org WG Subject: RE: [OAUTH-WG] Error Encoding: Conclusion I'll first review the proposed text (as a WG member) and raise any issues remaining (if any). I will wait until the ABNF text is provided before publishing another version. EH > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Thursday, May 31, 2012 10:54 AM > To: Eran Hammer > Cc: Mike Jones; oauth@ietf.org WG; Hannes Tschofenig > Subject: Re: [OAUTH-WG] Error Encoding: Conclusion > > Eran, could you publish a new draft version by Sunday with these > changes incorporated? That should give the working group enough time > to look at these few paragraphs. > > In the meanwhile we are working on addressing the ABNF issue Sean > raised and we will then go for another update. > > Ciao > Hannes > > On May 31, 2012, at 8:20 PM, Hannes Tschofenig wrote: > > > Hi Mike, > > > > thank you for compiling the text. It looks good to me. I have not > > seen > anyone from the working group screaming either. > > > > Eran, can you incorporate these changes into the next draft version? > > > > Ciao > > Hannes > > > > On May 30, 2012, at 2:10 AM, Mike Jones wrote: > > > >> I've made another set of updates to a copy of Core -26 to address > >> the > questions raised by Eran and David below (attached). > >> > >> An unrelated change that you should probably pick up, Eran is > >> adding this > to the <front> section, so that the heading shows that the draft is a > product of the "OAuth Working Group" rather than the "Network Working Group": > >> <area>Security</area> > >> <workgroup>OAuth Working Group</workgroup> > >> > >> One change I didn't make, but that should be considered, is to > >> delete the > reference to OASIS.saml-core-2.0-os, since it is used by no <xref> in > the document. > >> > >> The new proposed text for Section 7.2 follows: > >> > >> 7.2. Error Response > >> > >> If a resource access request fails, the resource server SHOULD inform > >> the client of the error. While the specific error responses possible > >> and methods for transmitting those errors when using any particular > >> access token type are beyond the scope of this specification, any > >> "error" code values defined for use with OAuth resource access > >> methods MUST be registered (following the procedures in > >> Section 11.4). > >> > >> Specifically, when the OAuth resource access method uses an "error" > >> result parameter to return an error code value that indicates the > >> resource access error encountered, then these error code values MUST > >> be registered. Values for these "error" codes MUST NOT include > >> characters outside the set %x20-21 / %x23-5B / %x5D-7E. When an > >> "error" code value is registered for use by an OAuth resource access > >> method, should that same code already be registered for use by > >> another OAuth resource access method or at a different OAuth error > >> usage location, then the meaning of that error code value in in the > >> new registration MUST be consistent with the its meaning in prior > >> registrations. > >> > >> The OAuth resource access error registration requirement applies only > >> to "error" code values and not to other means of returning error > >> indications, including HTTP status codes, or other error-related > >> result parameters, such as "error_description", "error_uri", or other > >> kinds of error status return methods that may be employed by the > >> resource access method. There is no requirement that OAuth resource > >> access methods employ an "error" parameter. > >> > >> Hopefully incorporating these changes will enable us to close the > remaining DISCUSS issues on both the Core and Bearer drafts. > >> > >> Thanks all, > >> -- > >> Mike > >> > >> > >> From: Eran Hammer [mailto:eran@hueniverse.com] > >> Sent: Wednesday, May 23, 2012 11:45 PM > >> To: David Recordon; Mike Jones; Hannes Tschofenig > >> Cc: oauth@ietf.org WG > >> Subject: RE: [OAUTH-WG] Error Encoding: Conclusion > >> > >> With the exception of section 7.2, the changes look reasonable and > >> will be > applied in the next revision. > >> > >> The new section 7.2 is confusion and does not explain the new registry. > The section introduces a new requirement to register 'any error codes > defined for use with OAuth resource access methods'. This requirement > is too vague. > >> > >> I have no clue how to (for example) apply this text to the MAC draft. > Adding to David's list below: > >> > >> * Should the HTTP status codes used by the MAC spec as currently > >> written > be registered (since no guidance is given to the use of an error parameter)? > >> * Does this introduce a requirement to add an error parameter? > >> * Does the parameter need to / should be called 'error'? > >> * What about future methods in which errors are not simply > >> expressed in > the form of a fixes string? > >> > >> EH > >> > >> > >> From: David Recordon [mailto:recordond@gmail.com] > >> Sent: Wednesday, May 23, 2012 11:38 PM > >> To: Mike Jones; Hannes Tschofenig; Eran Hammer > >> Cc: oauth@ietf.org WG > >> Subject: Re: [OAUTH-WG] Error Encoding: Conclusion > >> > >> Honestly still trying to fully wrap my head around what's going on > >> here > since it seems far more complex than the threads are alluding to. In > any case, does Mike's text address what Eran brought up as needed in > the thread Hannes referenced or is Eran wrong? > >> > >> The core spec currently provides full guidance and definition for > >> error > extensibility. Extending the registry's scope means the need for > non-trivial new text that: > >> > >> * explains the process of adding new errors for endpoints not > >> defined by > this specification, > >> * finds a common ground for value restrictions beyond what is > >> already > listed, > >> * guide authors of future HTTP authentication schemes meant for use > with OAuth (e.g. MAC) for their requirements for using the error > registry, and > >> * address the very likely scenario of the same error code carrying > different meanings in different endpoints, or an extension that adds a > location to a code already defined elsewhere - something very likely > to happen if you cross the two very different domains (OAuth > endpoints, Protected resource endpoints). This requires changing the > entire structure of the registry to create separate records for each code/location pair. > >> > >> Thanks, > >> --David > >> > >> On Wed, May 23, 2012 at 10:22 PM, Mike Jones > <Michael.Jones@microsoft.com> wrote: > >> Thanks Hannes. In the interest of hopefully completing the edits > >> to > remove the DISCUSS issues for the Bearer and Core specs in the next > few days so that we can send the docs to the RFC editors, I'd like to > propose specific language for the Core spec to address both of the > consensus call issue resolutions. After there's consensus on the > specific text for Core, it will be easy for us to add a reference in > Bearer to the language in Core for the error syntax restrictions and > to use the OAuth errors registry. I'll do that in parallel with the discussions on the proposed core language changes. > >> > >> > >> > >> A summary of the changes I made in response to the consensus call > conclusions are: > >> > >> * Add syntax restrictions for "error", "error_description", and > "error_uri" from Bearer to Core > >> > >> * Add section 7.2 about error responses from resource access requests > >> > >> * Add "resource access error response" to the category of OAuth > errors that can be registered > >> > >> > >> > >> Additional editorial changes that I made as I encountered issues in > >> the > document were: > >> > >> * Updated out of date references, especially the draft-hardt-oauth-01 > reference, which contained an invalid link > >> > >> * Added Derek Atkins to the list of chairs > >> > >> * Added Yaron Goland's middle initial Y. (since he prefers to include it > in publications) > >> > >> * Replaced use of the deprecated <appendix> element, which > prevented the spec from building with strict checking, with a > <section> element in the <back> section (which creates an appendix) > >> > >> > >> > >> To make it easy to incorporate these changes into the document and > >> so > the proposed changes are unambiguous, I produced an edited version of > Core -26 containing these changes. The xml, txt, and html versions > are attached to facilitate review. Pertinent diffs from the .txt version follow. > >> > >> > >> > >> Cheers, > >> > >> -- Mike > >> > >> > >> > >> 683c683,684 > >> > >> < notation of [RFC5234]. > >> > >> --- > >> > >>> notation of [RFC5234]. Additionally, the rule URI-Reference is > >> > >>> included from Uniform Resource Identifier (URI) [RFC3986]. > >> > >> 1441c1441,1442 > >> > >> < REQUIRED. A single error code from the following: > >> > >> --- > >> > >>> REQUIRED. A single ASCII [USASCII] error code from the > >> > >>> following: > >> > >> 1474a1475,1476 > >> > >>> Values for the "error" parameter MUST NOT include > >>> characters > >> > >>> outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 1476c1478 > >> > >> < OPTIONAL. A human-readable UTF-8 encoded text providing > >> > >> --- > >> > >>> OPTIONAL. A human-readable ASCII [USASCII] text providing > >> > >> 1478a1481,1482 > >> > >>> Values for the "error_description" parameter MUST NOT > >>> include > >> > >>> characters outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 1482a1487,1489 > >> > >>> Values for the "error_uri" parameter MUST conform to the > >>> URI- > >> > >>> Reference syntax, and thus MUST NOT include characters > >>> outside > >> > >>> the set %x21 / %x23-5B / %x5D-7E. > >> > >> 1840c1840,1841 > >> > >> < REQUIRED. A single error code from the following: > >> > >> --- > >> > >>> REQUIRED. A single ASCII [USASCII] error code from the > >> > >>> following: > >> > >> 1873a1874,1875 > >> > >>> Values for the "error" parameter MUST NOT include > >>> characters > >> > >>> outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 1875c1877 > >> > >> < OPTIONAL. A human-readable UTF-8 encoded text providing > >> > >> --- > >> > >>> OPTIONAL. A human-readable ASCII [USASCII] text providing > >> > >> 1877a1880,1881 > >> > >>> Values for the "error_description" parameter MUST NOT > >>> include > >> > >>> characters outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 1881a1886,1888 > >> > >>> Values for the "error_uri" parameter MUST conform to the > >>> URI- > >> > >>> Reference syntax, and thus MUST NOT include characters > >>> outside > >> > >>> the set %x21 / %x23-5B / %x5D-7E. > >> > >> < REQUIRED. A single error code from the following: > >> > >> --- > >> > >>> REQUIRED. A single ASCII [USASCII] error code from the > >> > >>> following: > >> > >> 2325a2326,2327 > >> > >>> Values for the "error" parameter MUST NOT include > >>> characters > >> > >>> outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 2327c2329 > >> > >> < OPTIONAL. A human-readable UTF-8 encoded text providing > >> > >> --- > >> > >>> OPTIONAL. A human-readable ASCII [USASCII] text providing > >> > >> 2329a2332,2333 > >> > >>> Values for the "error_description" parameter MUST NOT > >>> include > >> > >>> characters outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 2333a2338,2340 > >> > >>> Values for the "error_uri" parameter MUST conform to the > >>> URI- > >> > >>> Reference syntax, and thus MUST NOT include characters > >>> outside > >> > >>> the set %x21 / %x23-5B / %x5D-7E. > >> > >> 2450c2460,2468 > >> > >> < The method in which the client utilized the access token to > >> > >> --- > >> > >>> The method in which the client utilizes the access token to > >> > >> 2479c2489 > >> > >> < Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw > >> > >> --- > >> > >>> Authorization: Bearer mF_9.B5f-4.1JqM > >> > >> 2503a2514,2533 > >> > >>> > >> > >>> 7.2. Error Response > >> > >>> > >> > >>> If a resource access request fails, the resource server SHOULD > >>> inform > >> > >>> the client of the error. While the specific error responses > >>> possible > >> > >>> and methods for transmitting those errors when using any > >>> particular > >> > >>> access token type are beyond the scope of this specification, > >>> any > >> > >>> error codes defined for use with OAuth resource access methods > >>> MUST > >> > >>> be registered (following the procedures in Section 11.4). > >> > >>> > >> > >>> > >> > >> 2602,2603c2624,2626 > >> > >> < (Section 4.2.2.1), or the token error response (Section 5.2), such > >> > >> < error codes MAY be defined. > >> > >> --- > >> > >>> (Section 4.2.2.1), the token error response (Section 5.2), or > >>> the > >> > >>> resource access error response (Section 7.2), such error codes > >>> MAY be > >> > >>> defined. > >> > >> 3444c3484,3485 > >> > >> < (Section 4.2.2.1), or token error response (Section 5.2). > >> > >> --- > >> > >>> (Section 4.2.2.1), token error response (Section 5.2), or > >>> resource > >> > >>> access error response (Section 7.2). > >> > >> 3596a3554,3557 > >> > >>> [USASCII] American National Standards Institute, "Coded > >>> Character > >> > >>> Set -- 7-bit American Standard Code for Information > >> > >>> Interchange", ANSI X3.4, 1986. > >> > >>> > >> > >> 3611,3612c3572,3573 > >> > >> < OAuth 2.0", draft-ietf-oauth-saml2-bearer-08 (work in > >> > >> < progress), August 2011. > >> > >> --- > >> > >>> OAuth 2.0", draft-ietf-oauth-saml2-bearer-12 (work in > >> > >>> progress), May 2012. > >> > >> 3616,3617c3577,3579 > >> > >> < Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-08 > >> > >> < (work in progress), July 2011. > >> > >> --- > >> > >>> Authorization Protocol: Bearer Tokens", > >> > >>> draft-ietf-oauth-v2-bearer-19 (work in progress), > >> > >>> April 2012. > >> > >> 3620,3623c3589,3591 > >> > >> < Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP > >> > >> < Authentication: MAC Access Authentication", > >> > >> < draft-ietf-oauth-v2-http-mac-00 (work in progress), > >> > >> < May 2011. > >> > >> --- > >> > >>> Hammer-Lahav, E., "HTTP Authentication: MAC Access > >> > >>> Authentication", draft-ietf-oauth-v2-http-mac-01 > >>> (work in > >> > >>> progress), February 2012. > >> > >> 3626c3594 > >> > >> < Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 > >> > >> --- > >> > >>> McGloin, M., Hunt, P., and T. Lodderstedt, "OAuth 2.0 > >> > >> 3628,3629c3596,3597 > >> > >> < draft-ietf-oauth-v2-threatmodel-00 (work in progress), > >> > >> < July 2011. > >> > >> --- > >> > >>> draft-ietf-oauth-v2-threatmodel-02 (work in > >>> progress), > >> > >>> February 2012. > >> > >> 3468,3546d3503 > >> > >> < Brian Eaton, Yaron Goland, Dick Hardt, and Allen Tom. > >> > >> 3639c3609,3639 > >> > >>> Brian Eaton, Yaron Y. Goland, Dick Hardt, and Allen Tom. > >> > >> 3468,3546d3503 > >> > >> < Yaron Goland, Brent Goldman, Kristoffer Gronowski, Justin Hart, > >> > >> 3644,3645c3644,3656 > >> > >>> Yaron Y. Goland, Brent Goldman, Kristoffer Gronowski, Justin > >>> Hart, > >> > >> 3468,3546d3503 > >> > >> < This document was produced under the chairmanship of Blaine Cook, > >> > >> < Peter Saint-Andre, Hannes Tschofenig, and Barry Leiba. The area > >> > >> < directors included Lisa Dusseault, Peter Saint-Andre, and Stephen > >> > >> < Farrell. > >> > >> 3646a3658,3661 > >> > >>> This document was produced under the chairmanship of Blaine > >>> Cook, > >> > >>> Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, and Derek Atkins. > >> > >>> The area directors included Lisa Dusseault, Peter Saint-Andre, > >>> and > >> > >>> Stephen Farrell. > >> > >> > >> > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > >> Sent: Wednesday, May 23, 2012 11:27 AM > >> To: oauth@ietf.org WG > >> Subject: [OAUTH-WG] Error Encoding: Conclusion > >> > >> > >> > >> Hi all, > >> > >> > >> > >> on May 10th we called for consensus on an open issue regarding the > >> error > encoding. Here is the link to the call: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg08994.html > >> > >> > >> > >> Thank you all for the feedback. The conclusion of the consensus > >> call was > to harmonize the encoding between the two specifications by > incorporating the restrictions from the bearer specification into the > base specification. The error encoding will go into the core > specification and the bearer specification will reference it. > >> > >> > >> > >> Ciao > >> > >> Hannes & Derek > >> > >> > >> > >> _______________________________________________ > >> > >> 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 > >> > >> > >> <draft-ietf-oauth-v2-26+mbj-2.xml><draft-ietf-oauth-v2-26+mbj- > 2.txt><draft-ietf-oauth-v2-26+mbj-2.html> > >
- [OAUTH-WG] Error Encoding: Conclusion Hannes Tschofenig
- Re: [OAUTH-WG] Error Encoding: Conclusion Mike Jones
- Re: [OAUTH-WG] Error Encoding: Conclusion David Recordon
- Re: [OAUTH-WG] Error Encoding: Conclusion Eran Hammer
- Re: [OAUTH-WG] Error Encoding: Conclusion Mike Jones
- Re: [OAUTH-WG] Error Encoding: Conclusion Hannes Tschofenig
- Re: [OAUTH-WG] Error Encoding: Conclusion Hannes Tschofenig
- Re: [OAUTH-WG] Error Encoding: Conclusion Eran Hammer
- Re: [OAUTH-WG] Error Encoding: Conclusion Mike Jones
- Re: [OAUTH-WG] Error Encoding: Conclusion Eran Hammer
- [OAUTH-WG] ABNF Re: Error Encoding: Conclusion William Mills
- Re: [OAUTH-WG] ABNF Re: Error Encoding: Conclusion Mike Jones
- Re: [OAUTH-WG] ABNF Re: Error Encoding: Conclusion William Mills
- Re: [OAUTH-WG] ABNF Re: Error Encoding: Conclusion Mike Jones
- Re: [OAUTH-WG] Error Encoding: Conclusion Mike Jones
- Re: [OAUTH-WG] Error Encoding: Conclusion Eran Hammer