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.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
