On Wed, Nov 30, 2016 at 12:15 AM, Martin Thomson <[email protected]> wrote:
> On 30 November 2016 at 15:52, Richard Barnes <[email protected]> wrote: > > So, dear HTTP editor, which code should we use? > > No need to be facetious :) > > I was agreeing with Ted, if that wasn't clear. 400 is your grab bag > for "requests you don't like". 403 is generally used for cases where > authentication has been dealt with, but that is (still) insufficient. > I think that it's perfectly good for cases where the account or > signature is forbidden from making a change. > > Changes of Terms of Service [sic - Changed?] 403 => 400 seems like a > better choice > Pre-Authorization 403 is probably OK here > > There doesn't seem to be a good rule in these cases, but the risk is > that you slap 403 on every request that the server might want to > reject on the basis of ...stuff. > My inclination here would be to basically cut "stuff" into two tranches: - 400 for stuff that can go wrong at the transport layer, e.g., signature validation failure, nonce reuse - 403 for stuff that can go wrong at the application logic layer, e.g., refusal to authorize for an identifier That means 403 for changes to terms of service / userActionRequired, but 400 for badSignatureAlgorithm. I've updated the PR correspondingly. https://github.com/ietf-wg-acme/acme/pull/218 --Richard On Wed, Nov 30, 2016 at 12:15 AM, Martin Thomson <[email protected]> wrote: > On 30 November 2016 at 15:52, Richard Barnes <[email protected]> wrote: > > So, dear HTTP editor, which code should we use? > > No need to be facetious :) > > I was agreeing with Ted, if that wasn't clear. 400 is your grab bag > for "requests you don't like". 403 is generally used for cases where > authentication has been dealt with, but that is (still) insufficient. > I think that it's perfectly good for cases where the account or > signature is forbidden from making a change. > > Changes of Terms of Service [sic - Changed?] 403 => 400 seems like a > better choice > Pre-Authorization 403 is probably OK here > > There doesn't seem to be a good rule in these cases, but the risk is > that you slap 403 on every request that the server might want to > reject on the basis of ...stuff. >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
