Thanks. I will dig it up. On Fri, Nov 14, 2014 at 10:54 Bill Mills <wmills_92...@yahoo.com> wrote:
> I sent some feedback on that section in a different message on list. > > > On Friday, November 14, 2014 12:41 PM, Nat Sakimura <sakim...@gmail.com> > wrote: > > > That pretty much was the conclusion we reached. I believe that it was what > the F2F room inclined to. So, for -04, we added a section on error response > but it doesn't have those granular errors. > On Fri, Nov 14, 2014 at 07:07 John Bradley <ve7...@ve7jtb.com> wrote: > > <hatoff> Nat and I discussed it yesterday and I am still personally > unconvinced that the errors from the authorization endpoint are helpful. > So I am personally against adding specific errors for S256_unsupported > </hatoff> > > On Nov 14, 2014, at 6:52 AM, Nat Sakimura <sakim...@gmail.com> wrote: > > <editorhatoff>I find not much, if any. </editorhatoff > > > > On Fri, Nov 14, 2014 at 06:27 Brian Campbell <bcampb...@pingidentity.com> > wrote: > > I struggle to see the value in adding more fine grained machine readable > error messages for this. > > Do we really want clients to try and negotiate the code_challenge_method > using browser redirects? Especially in light of the fact that we'll likely > also be discouraging AS's from redirecting on some error conditions when > there's no user interaction. > > On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura <sakim...@gmail.com> wrote: > > As discussed at F2F today at IETF 91 OAuth WG, there has been some request > to have a more fine grained machine readable error messages. > > Currently, it only returns the error defined in RFC6749 and any more > details is supposed to be returned in error_descripton and error_uri. > > So, I came up with the following proposal. If WG agrees, I would put text > embodying it into the draft-04. Otherwise, I would like to go as is. You > have to speak out to put it in. (I am sending out -03, which we meant to > send before submit freeze, without it..) > > nError response to authorization request > lReturns invalid_request with additional error param spop_error with the > following values: > ▪S256_unsupported > ▪none_unsupported > ▪invalid_code_challenge > Clients MUST NOT accept the downgrade > request through this as it may be a downgrade > attack by a MITM. > nError response to token request > lReturns invalid_request with additional error param spop_error with the > following values: > ▪invalid _code_verifier > ▪verifier_challenge_mismatch > nAuthorization server should return more descriptive information on > lerror_description > lerror_uri > > > > > _______________________________________________ > 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 > > > > _______________________________________________ > 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
