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).
On 22/03/17 17:35, Daniel McCarney wrote: > 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 protected]> > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
