Hi Eric,
Replies are inline below, prefixed by “Mike>”. In summary, unless you want to
see additional text added giving examples of substitution attacks, I believe
that -04 addressed all of your review comments. Let us know, and if so, we’ll
turn the crank and publish an -05 doing so.
Excellent point! The specs (OAuth2 and OIDC) are completely silent on
what should happen if an HTTP transport error occurs. Maybe that whole
space should have it's own blog post:)
Regardless of the OAuth2/OIDC error code, clients already have to deal
with HTTP codes like 503 "Service Unavailab
On 2019-02-22 10:29 a.m., George Fletcher wrote:
> I believe Torsten proposed an "authentication_failed" error response
> in a different context. Possibly we could use that?
>
> Alternatively, OpenID Connect defines a 'login_required' error that
> could work in this context as well. It doesn't fit
I believe Torsten proposed an "authentication_failed" error response in
a different context. Possibly we could use that?
Alternatively, OpenID Connect defines a 'login_required' error that
could work in this context as well. It doesn't fit the semantic as
defined in the OIDC spec, but as an er
HTTP 429 sounds fine for the HTTP response code, but what about the OAuth
error code string? "invalid_grant" seems closest but doesn't sound right
because if the app tries the same request again later it would be valid.
On Fri, Feb 22, 2019 at 6:02 AM George Fletcher wrote:
> +1 for using 429
+1 for using 429
On 2/22/19 2:09 AM, David Waite wrote:
I don’t believe that any of the currently registered error codes are
appropriate for indicating that the password request is invalid, let
alone a more specific behavior like rate limiting.
It is also my opinion that 400 Bad Request shoul
