Re: [Acme] Conflicting requirements for retrieving an ACME account that is already bound to an external account

[Jacob Hoffman-Andrews <[e-mail]>]

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 the externalAccountBind field / not
re-verify it, and return an account object whose externalAccountBinding
field is set based on the contents of the CA's database.

> 1. A client should be permitted to omit "externalAccountBinding" from a
newAccount request when retrieving an existing account from a server that
requires external account binding.  (External account binding is a one-time
operation; as soon as an ACME account and an external account are bound
once, they're bound forever).
> 2. When a client does provide "externalAccountBinding" in a newAccount
request to retrieve an existing account from a server that requires
external account binding, the server should be required to verify that
binding and ensure that it links to the exact same external account to
which the ACME account is already bound.

I think an errata is not needed to make forward progress, but if you want
to do an errata for 1, I'd support it. I'm not enthusiastic about 2.

In general I think providing the option to look up an account by key was a
mistake. 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. Particularly in the case where the client is storing both an
account key and an external account binding, I think it's reasonable to ask
that the client store the account URL rather than add additional complexity
to the account-lookup part of the standard.