Subject: Re: [Acme] Missing structure and unspecified parts in "Account Creation"

From: Sophie Herold <[email-masked]>
Date: Mon, 20 Mar 2017 09:50:43 +0100

PR for 1.-3.
<https://github.com/ietf-wg-acme/acme/pull/280>

PR for 4.
<https://github.com/ietf-wg-acme/acme/pull/281>

Issue related to 4.
<https://github.com/ietf-wg-acme/acme/issues/278>

On 20/02/17 16:17, Sophie Herold wrote:
> 1.
>   I cannot find where the response to account updates is specified.
> 
>   Boulder replies with "202 Accepted" and an account object. Since
>   updates with trivial payload should be used for account information,
>   it seems to be expected that an account object is returned. The
>   specified response status for "Account deactivation" is "200 OK".
>   It would be consistent to specify the same response status for
>   account updates I guess?
> 
> 2.
>   The client should be able to choose between "Account URI recovery"
>   and "Account Creation", if needed. A possible way would be to clarify
>   that account creations with trivial payload MUST be rejected. However,
>   if an account exists, the "Content-Location" header and "200 OK" is
>   returned, independent of the payloads content. Therefore a trivial
>   payload could be used to check if an account with the used key exists,
>   without creating it.
> 
> 3.
>   As "6.3.4.  Account deactivation", other queries should get their own
>   sub-sub sections. Something like
>    - "6.3.x Account URI recovery" ("new-account", maybe trivial payload)
>    - "6.3.x Account update"
>    - "6.3.x Account information" (update with trivial payload)
> 
> 4.
>   Is it really an account URI or rather an account URL? Some fields
>   changed from "uri" to "url". I guess, all occurrences of URIs should
>   be URLs. The only exception that I see is the "type" field in the
>   "Problem Details" responses.
>

---

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

Thanks for following up on your initial message with PR's Sophie.

For PR 281 I left a small comment but otherwise LGTM.

For PR 280 - I think the proposed changes are great with the exception of
one question I have RE: the mechanism to differentiate the account URI
recovery POSTs from account creation POSTs.
Do you think it would be clearer to separate the account URI recovery to a
new endpoint?
It seems like the empty JWS payload approach would work, but we're adding
more complexity to the account creation endpoint to allow it to double as
the account URI recovery endpoint. Maybe it's time to separate it properly.
What does the list think?

On Mon, Mar 20, 2017 at 4:50 AM, Sophie Herold <[email-masked]>
wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Sophie Herold <[email-masked]>
Date: Wed, 22 Mar 2017 18:16:59 +0100

Hi Daniel,

I thought that there shouldn't be extra complexity arising from my PR,
because a "stub account object" contains a "contact" field anyways.
Hence, a server implementation should check if it is contained in the
payload. I think I was implicitly reading a MUST for the "contact" field
which is not there (yet).