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..)
nErrorresponse to authorization requestlReturns invalid_request withadditional
error param spop_error with the following values:
▪S256_unsupported▪none_unsupported▪invalid_code_challengeClientsMUST NOT accept
the downgrade request throughthis as it may be a downgrade attack by a MITM.
nErrorresponse to token requestlReturns invalid_request withadditional error
param spop_error with the following values: ▪invalid
_code_verifier▪verifier_challenge_mismatchnAuthorizationserver should return
more descriptive information on lerror_descriptionlerror_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
