Re: [OAUTH-WG] Error Encoding: Conclusion

[Eran Hammer <[e-mail]>]

The new text published today for section 7.2 isn't acceptable. It seems (the lanaguage is unclear when it comes to its actual requirements) to indicate that any protocol used for OAuth token authentication using an error parameter named "error" must use the new registry. Any authentication method not using a parameter named "error" does not have to comply with this.

Questions:

Can anyone write extensions where the parameter name is "err" and ignore this entire registry? The text already states that returning errors not using a parameter are excluded.
If someone defines a new HTTP authentication scheme outside of this WG which may be used for token authentication and uses "error", does this establish any requirement to use the registry? What happens when the WG tries to adopt it for OAuth usage?

The new text does not address the chairs instruction to break the registry into separate tables for each location. As specified, IANA is going to create a single table. Since this was announced in a consensus call by the chairs, the new text must comply unless the chairs change their mind on this.

EH




> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Saturday, June 02, 2012 1:08 AM
> To: Eran Hammer; Hannes Tschofenig
> Cc: [e-mail] WG
> Subject: RE: [OAUTH-WG] Error Encoding: Conclusion
> 
> After speaking with the chairs, I volunteered to write a draft of the ABNF text
> to keep things moving towards completion.  An updated version of Core
> including the ABNF and my previous proposed changes addressing the
> consensus call issues is attached.  As long as I was at it, I also fixed the issues
> that Phil identified and ran a spell/grammar check on the draft and corrected
> the issues identified.  The significant diffs since my previous proposed
> version, other than the new ABNF section, also follow inline for working
> group review.
> 
> I'll send a separate note with the new ABNF section outlining aspects of the
> ABNF that I believe should be specifically reviewed by the working group.
> 
> Hopefully a new Core draft with all of these resolutions can be published
> shortly, at which point I'll be able to publish a Bearer draft that references
> these resolutions, enabling us to close the outstanding DISCUSS issues.
> 
> 				Best wishes,
> 				-- Mike
> 
> P.S.  Bill, looking at it further, you were right that vestiges of the leading
> ALPHA in the error syntax remained in my previous draft, making it
> inconsistent.  I've addressed this in the new draft.
> 
> 715,720c715,720
> <    o  specifies the client type as described in Section 2.1,
> <    o  provides its client redirection URIs as described in
> <       Section 3.1.2, and
> <    o  includes any other information required by the authorization
> <       server (e.g. application name, website, description, logo image,
> <       the acceptance of legal terms).
> ---
> >    o  specify the client type as described in Section 2.1,
> >    o  provide its client redirection URIs as described in Section 3.1.2,
> >       and
> >    o  include any other information required by the authorization server
> >       (e.g. application name, website, description, logo image, the
> >       acceptance of legal terms).
> 807c807
> <    secret, it is exposed to the resource owner, and MUST NOT be used
> ---
> >    secret; it is exposed to the resource owner, and MUST NOT be used
> 2663,2666c2663,2666
> <    Error codes MUST conform to the error-code ABNF, and SHOULD be
> ---
> >    Error codes MUST conform to the error ABNF, and SHOULD be
> 2669,2670c2669,2670
> <      error-code   = ALPHA *error-char
> <      error-char   = "-" / "." / "_" / DIGIT / ALPHA
> ---
> >      error      = 1*error-char
> >      error-char = %x20-21 / %x23-5B / %x5D-7E
> <    client, was issued to the that client by the authorization server.
> ---
> >    client was issued to that client by the authorization server.
> 3128c3128
> <    respectively.  For older browsers, javascript framebusting techniques
> ---
> >    respectively.  For older browsers, JavaScript framebusting
> > techniques
> 3178c3178
> <    ([RFC5226]) after a two weeks review period on the [TBD]@ietf.org
> ---
> >    ([RFC5226]) after a two week review period on the [TBD]@ietf.org
> 3238c3238
> <    Specification Required ([RFC5226]) after a two weeks review period on
> ---
> >    Specification Required ([RFC5226]) after a two week review period
> > on
> 3398,3403c3398,3403
> <    registered with a Specification Required ([RFC5226]) after a two weeks
> ---
> >    registered with a Specification Required ([RFC5226]) after a two
> > week
> 3463,3465c3463,3465
> <    after a two weeks review period on the [TBD]@ietf.org mailing list,
> ---
> >    after a two week review period on the [TBD]@ietf.org mailing list,
> 3593a3594,3598
> >    [I-D.ietf-httpbis-p7-auth]
> >               Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part
> >               7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in
> >               progress), March 2012.
> >
> 3616,3621d3620
> <    [OASIS.saml-core-2.0-os]
> <               Cantor, S., Kemp, J., Philpott, R., and E. Maler,
> <               "Assertions and Protocol for the OASIS Security Assertion
> <               Markup Language (SAML) V2.0", OASIS Standard saml-core-
> <               2.0-os, March 2005.
> <
> 3628,3633c3627,3630
> <    McGloin, Phil Hunt, and Anthony Nadalin.
> ---
> >    McGloin, Phil Hunt, and Anthony Nadalin.  The ABNF section was
> >    drafted by Michael B. Jones.
> 
> -----Original Message-----
> From: Eran Hammer [mailto:[e-mail]]
> Sent: Thursday, May 31, 2012 12:35 PM
> To: Hannes Tschofenig
> Cc: Mike Jones; [e-mail] 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:[e-mail]]
> > Sent: Thursday, May 31, 2012 10:54 AM
> > To: Eran Hammer
> > Cc: Mike Jones; [e-mail] 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:[e-mail]]
> > >> Sent: Wednesday, May 23, 2012 11:45 PM
> > >> To: David Recordon; Mike Jones; Hannes Tschofenig
> > >> Cc: [e-mail] 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:[e-mail]]
> > >> Sent: Wednesday, May 23, 2012 11:38 PM
> > >> To: Mike Jones; Hannes Tschofenig; Eran Hammer
> > >> Cc: [e-mail] 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
> > <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Hannes Tschofenig
> > >> Sent: Wednesday, May 23, 2012 11:27 AM
> > >> To: [e-mail] 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
> > >>
> > >> [e-mail]
> > >>
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >>
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> [e-mail]
> > >> 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>
> > >
>