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
