Re: [OAUTH-WG] Adding machine readable errors to SPOP?

Thanks. I will dig it up.
On Fri, Nov 14, 2014 at 10:54 Bill Mills <wmills_92105@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 <sakimura@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 <ve7jtb@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 <sakimura@gmail.com> wrote:
>
> <editorhatoff>I find not much, if any. </editorhatoff >
>
>
> On Fri, Nov 14, 2014 at 06:27 Brian Campbell <bcampbell@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 <sakimura@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
>
>
>