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 <sophie_her...@hemio.de> wrote: > 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. > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
