Subject: [Acme] Effects of the account recovery process described in Section 7.3, Account Creation

From: Zach Shepherd <[email-masked]>
Date: Wed, 22 Mar 2017 05:14:05 +0000

The following feedback is based on 8010a31 (current HEAD of master).

Section 7.3, Account Creation, states "If the server already has an account registered with the provided account key, then it MUST return a response with a 200 (OK) status code and provide the URI of that account in the Location header field. This allows a client that has an account key but not the corresponding account URI to recover the account URI."

This section does not specify what the server should do with the data in the request payload, such as contact information. Ignoring the data from the request, using the data from the request to update the registered account, and union-ing the data from the two sources each seem like sane implementation decisions. This may lead to significant behavioral differences between server implementations, complicating client implementation.

I would propose either:
a) Indicating that the server must discard the information from the account creation request in this case.
b) Indicating that the server must treat the request as an account update operation.

Given that updating the account as a part of the recovery operation could be perceived as a surprising side effect and given that there is already a well-defined way to perform an update to an account, I would prefer option (a).

Regards,
Zach Shepherd

---

From: Daniel McCarney <[email-masked]>
Date: Wed, 22 Mar 2017 12:42:07 -0400

Hi Zach,

I agree with your assessment. I think adding language specifying that the
server not treat the account creation request as an update to the existing
account is the best option.

- Daniel

On Wed, Mar 22, 2017 at 1:14 AM, Zach Shepherd <[email-masked]> wrote:

> Section 7.3, Account Creation, states "If the server already has an
> account registered with the provided account key, then it MUST return a
> response with a 200 (OK) status code and provide the URI of that account in
> the Location header field. This allows a client that has an account key but
> not the corresponding account URI to recover the account URI."
>
> This section does not specify what the server should do with the data in
> the request payload, such as contact information. Ignoring the data from
> the request, using the data from the request to update the registered
> account, and union-ing the data from the two sources each seem like sane
> implementation decisions. This may lead to significant behavioral
> differences between server implementations, complicating client
> implementation.
>
> I would propose either:
> Given that updating the account as a part of the recovery operation could
> be perceived as a surprising side effect and given that there is already a
> well-defined way to perform an update to an account, I would prefer option
> (a).
>
> Regards,
> Zach Shepherd
>
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>