Re: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer Spec

[Eran Hammer <[e-mail]>]

I am only talking about the error code registry (location and value restrictions).

Go back to your responses to the IESG questions about adding the errors to the core spec's registry and you'll clearly see how you failed to represent the WG consensus. Instead, you should have pointed to the WG consensus regarding the scope of the error registry in the core spec, and only suggesting adding a registry in the bearer for that purpose alone.

EH



> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Wednesday, May 09, 2012 4:33 PM
> To: Eran Hammer; Hannes Tschofenig; [e-mail] WG
> Subject: RE: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer
> Spec
> 
> Per the earlier correction to my typo, the DISCUSS was on the bearer spec.  It
> asked me to reference syntax restrictions for scope and error values the core
> spec, that it turns out were not uniformly present there.  The chairs decided
> to ask the working group whether to add them there (allowing me to satisfy
> the bearer DISCUSS) or whether not to (in which case, we'll have to come up
> with a different resolution).
> 
> I believe it was reasonable of the person filing the DISCUSS to expect the
> syntax for these elements to be the same between the two specs, and so
> reasonable of the chairs to ask the question.
> 
> To my knowledge, there was no working group consensus that the syntax of
> these elements should be different across the OAuth specs (despite your
> apparent representation to the contrary below).  In fact, at least in the case
> of the scope parameter, there was clear WG consensus tracked as
> http://trac.tools.ietf.org/wg/oauth/trac/ticket/27 to make them be the
> same.
> 
> Yes, I have expressed my personal opinions as a member of the working
> group in appropriate contexts (as have you).  But I have never represented
> my personal opinions as working group consensus unless that was actually
> the case, your statements below notwithstanding.
> 
> 				-- Mike
> 
> P.S.  As you know, the other outstanding consensus call about registering
> OAuth Errors was a result of a DISCUSS on the bearer spec that explicitly
> asked us to register the bearer errors in the existing OAuth Errors Registry -
> not a result of me suggesting that that should occur or me failing to
> accurately represent the working group discussions on that issue to date.
> Again, it's a fair question raised by an IESG member, and one that Stephen
> Farrell asked the chairs to make a working group consensus call on, so that
> DISCUSS can be addressed as well.
> 
> -----Original Message-----
> From: Eran Hammer [mailto:[e-mail]]
> Sent: Wednesday, May 09, 2012 4:05 PM
> To: Mike Jones; Hannes Tschofenig; [e-mail] WG
> Subject: RE: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer
> Spec
> 
> There was no such discuss on the core specification.
> 
> The only open discuss on the core specification related to character sets is to
> translate the EXISTING prose into ABNF which will not have any
> implementation impact.
> 
> The proper response to the bearer specification discuss was to simply add a
> registry there, and to clearly state that this matter was discussed extensively
> by the WG and the design committee. Instead of representing this
> information to the IESG, you failed to do your job as editor and offered your
> personal view which was rejected by the WG and recorded in the issue
> tracker at the time.
> 
> You don't get a second chance to insert your personal position during the
> IESG review process. As editor, you only get to represent the WG consensus
> when addressing issues. If you go and read my responses to the long list of
> discuss items on the core specification you will see that I represented views I
> personally did not agree with (the lack of interop, undefined security, etc.)
> because as editor, I don't get to go to the IESG and disrespect the WG's
> decision.
> 
> The IESG members rely on the editor to represent the WG decisions to them
> when addressing issues. You failed to do that, promoted your personal view,
> and now we are having this discussion all over again - a discussion that last
> time was only resolved by creating the design committee.
> 
> EH
> 
> 
> > -----Original Message-----
> > From: Mike Jones [mailto:[e-mail]]
> > Sent: Wednesday, May 09, 2012 3:41 PM
> > To: Eran Hammer; Hannes Tschofenig; [e-mail] WG
> > Subject: RE: [OAUTH-WG] Encoding of Errors in the Base and in the
> > Bearer Spec
> >
> > There was a DISCUSS on the core spec asking us to cite the character
> > set restrictions for scope and error values in the core spec, rather
> > than defining them in the bearer spec.  It turns out that I could not
> > do that as the core spec is currently written, because the character
> > set restrictions are not present in the core spec.  If they are added
> > to the core spec, I can satisfy the bearer DISCUSS by doing so.  If the
> restrictions are not added, I cannot.
> >
> > This consensus call is part of resolving this DISCUSS, which affects both
> specs.
> >
> > 				-- Mike
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Eran Hammer
> > Sent: Wednesday, May 09, 2012 3:35 PM
> > To: Hannes Tschofenig; [e-mail] WG
> > Subject: Re: [OAUTH-WG] Encoding of Errors in the Base and in the
> > Bearer Spec
> >
> > I am confused by the process here.
> >
> > The IESG review raised a LONG list of discuss items for the core
> specification.
> > I was able to successfully address all but three remaining issues:
> >
> > 1. Lack of ABNF - I will do it myself this week since no one else
> > bothered to offer their help.
> > 2. Registry rules - waiting for this to be cleared; have addressed the
> > issue but didn't hear back yet.
> > 3. Comment on not allowing a fragment in redirection and endpoint URIs
> > - waiting for text or item closed.
> >
> > Every other issue for this document has been closed.
> >
> > This WG cannot just go back after WG LC, IETF LC, and IESG review and
> > make changes. This work is done, and any change made at this point
> > must be for the sole purpose of addressing a discuss item. There are
> > no discuss items for
> > *this* document related to errors. They have all been raised in
> > detail, addressed, and closed!
> >
> > As for this survey -
> >
> > While I am still very much opposed to adding the protected resource
> > registry function to the core specification, this new issue clearly
> > demonstrate that this is not simply a matter of adding another error
> location.
> >
> > 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.
> >
> > Any change to the core specification MUST address all these items.
> > This is absolutely NOT a matter of simply adding another location or
> > throwing some extra ABNF. Adding such new text will require another
> > IETF LC and another IESG review - which are completely unjustified
> > based on where the document is in its IESG review process.
> >
> > The point of IESG review is to close issues with minimal changes, not
> > take it as an opportunity to sneak new functionality into the
> > document. And it's not like this WG has not debated these items
> > before, and made consensus calls on them.
> >
> > Not adding the protected resource location to the registry was the
> > result of intense negotiation both on the list and by the design
> > committee. What was the point of asking a few of us to spend hours on
> > the phone debating these issues and reaching a conclusion if it's
> > another popularity contest now. We had FULL consensus by the design
> > committee NOT to add the bearer errors to the core specification, and
> > this recommendation was fully supported by the WG and documented in
> the issues tracker.
> >
> > These WG surveys are an insult to proper process.
> >
> > EH
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf Of Hannes Tschofenig
> > > Sent: Wednesday, May 09, 2012 3:07 PM
> > > To: [e-mail] WG
> > > Subject: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer
> > > Spec
> > >
> > > Hi all,
> > >
> > > another issue that came up in Sean's IESG review was about the
> > > encoding of the error / error_description / error_uri in the base
> > > and in the bearer specification.
> > >
> > > As mentioned in my earlier mail about the registry for the error
> > > codes there are three error fields defined in the two specification
> > > and the error / error_description / error_uri fields are allowed to
> > > appear in different parts of an HTTP message.
> > > Depending on where they show up different encoding restrictions apply.
> > >
> > > For the core specification these error fields may appear in the
> > > * body of the HTTP message (encoded in JSON)
> > > * parameters to the query component of the redirection URI (using the
> > >   "application/x-www-form-urlencoded" format)
> > >
> > > For the bearer specification these error fields appear in the HTTP header.
> > > Consequently,
> > > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19
> > > says 'values for the "error" and "error_description" attributes MUST
> > > NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.'
> > >
> > > Now, here is the question. While these errors are essentially copied
> > > over from one spec to the other the different encoding restrictions
> > > make them different. Do we want different encodings of errors in the
> > > two
> > documents?
> > >
> > > So, I see two options:
> > >
> > > 1) Leave the encoding as it is. This means the encoding of the error
> > > / error_description / error_uri in the two specifications is different.
> > >
> > > 2) Harmonize the encoding between the two specifications by
> > > incorporating the restrictions from the bearer specification into
> > > the base
> > specification.
> > >
> > > Please indicate your preference by the end of next week (18th May
> 2012).
> > >
> > > Ciao
> > > Hannes
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/oauth
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> 
>