How about if it just returns 200 with no URL? That way the client can just look at the Location field to see whether an account exists or not.
https://github.com/ietf-wg-acme/acme/pull/308 On Thu, Apr 27, 2017 at 5:15 PM, Logan Widick <logan.wid...@gmail.com> wrote: > What would the server return if "only-return-existing" is true and the > account doesn't exist? > > On Thu, Apr 27, 2017 at 2:40 PM, Richard Barnes <r...@ipv.sx> wrote: > >> >> >> On Tue, Apr 18, 2017 at 1:34 AM, Hugo Landau <hlan...@devever.net> wrote: >> >>> > In reviewing a PR today noting that a client can find the account >>> URI for >>> > a key pair using a new-account request with an empty payload [1], >>> Jacob >>> > and I thought it might be a little more robust to use an explicit >>> signal. >>> > I've posted a PR that adds a "recovery" field to indicate to the >>> server >>> > that it should not create an account if one does not exist >>> already. Which >>> > is a little ironic in a request to an endpoint designed to create an >>> > account, but saves us creating a whole new endpoint. >>> > [1]https://github.com/ietf-wg-acme/acme/pull/296 >>> I don't think this should be called recovery. It's too reminiscent of >>> the old removed account recovery mechanisms and will be confusing. >>> >>> How about "existing": true? >>> >> >> Good idea. To be extra clear, I think I'm going to with >> "only-return-existing". >> >> >> _______________________________________________ >> 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
