Subject: [Acme] Account URI recovery

From: Richard Barnes <[email-masked]>
Date: Mon, 17 Apr 2017 18:45:34 -0400

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.

https://github.com/ietf-wg-acme/acme/pull/296

Please let me know if you have any comments on the approach here.

Thanks,
--Richard

---

From: Hugo Landau <[email-masked]>
Date: Tue, 18 Apr 2017 06:34:00 +0100

>    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?

---

From: Logan Widick <[email-masked]>
Date: Tue, 18 Apr 2017 00:48:18 -0500

>From the text, if the field isn't present, should the server act like it
was set to false?

If this new field is false, and an account exists, then what happens to the
pre-existing account, its orders, its certificates and its authorizations?

Sincerely,

Logan Widick

On Apr 17, 2017 17:45, "Richard Barnes" <[email-masked]> wrote:

> 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
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 27 Apr 2017 15:38:09 -0400

On Tue, Apr 18, 2017 at 1:48 AM, Logan Widick <[email-masked]>
wrote:

> was set to false

Correct.

>
> If this new field is false, and an account exists, then what happens to
> the pre-existing account, its orders, its certificates and its
> authorizations?
>

Same as before -- you get a 200 with the existing account.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Thu, 27 Apr 2017 15:40:15 -0400

> How about "existing": true?

Good idea.  To be extra clear, I think I'm going to with
"only-return-existing".

---

From: Logan Widick <[email-masked]>
Date: Thu, 27 Apr 2017 16:15:46 -0500

What would the server return if "only-return-existing" is true and the
account doesn't exist?

---

From: Richard Barnes <[email-masked]>
Date: Thu, 27 Apr 2017 17:38:56 -0400

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