Clients already have to store one piece of state (the account
key), and asking them to store a second piece of state (the account URL) is
not onerous.
I would disagree: there is a key difference between the two pieces of
state, especially to systems using a declarative desired state and a
> I understand "reflect" to mean "echo what the client sent."
Thanks Jacob! I hadn't thought of interpreting it that way.
I've just done a quick review of other instances of the word "reflect" in the
document. I think some instances obviously mean "echo what the client sent"
(e.g., [1]),
I think this is the key bit:
> - Since the server has not verified the binding, its response 'MUST NOT
reflect the "externalAccountBinding" field in the resulting account object'.
I understand "reflect" to mean "echo what the client sent." So I think it's
acceptable for the server to ignore
https://tools.ietf.org/html/rfc8555#section-7.1.2 says (emphasis mine):
'externalAccountBinding (optional, object): Including this field in a
newAccount request indicates approval by the holder of an existing
non-ACME account to bind that account to this ACME account. This
