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
