<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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to