Subject: Re: [Acme] Allowing clients to understand the account creation functionality supported by a server

From: Logan Widick <[email-masked]>
Date: Thu, 23 Mar 2017 19:34:26 -0500

I think that there should be a way for servers to tell clients what
types of contact information and what types of identifiers are
supported. Perhaps some part of the directory object could have an
array of dummy contacts to show off the URI schemes. For example:

contactTypes: ["mailto:[email-masked]", "tel:000-000-0000"]

Alternatively, the contactTypes may be a list of schemes. For example:

contactTypes: ["mailto", "tel"]

Another part of the directory object could have information on
supported identifiers. For example:

identifierTypes: ["dns"]

Alternatively, the identifierTypes could include possible challenge
types that the server may issue. For example:

identifierTypes: [
    {"identifierType": "dns", "challengeTypes": ["http", "tls-sni", "dns"]}
]

Or, the identifierTypes may include information on possible
authorizations. For example, consider an ACME server that requires 2
authorizations for a domain. One of the two authorizations must
require a successful "http" or "tls-sni" challenge, while the other
authorization requires a successful "dns" challenge. Then, the
identifierTypes may look like (with // lines as comments only):

 identifierTypes: [
    {"identifierType": "dns", "authorizationTypes": [
          //first authorization: client must complete either HTTP or
TLS-SNI challenge
          ["http", "tls-sni"],
          //second authorization: client must complete DNS challenge
          ["dns"]
     ]}
]

I have three options above for identifiers as I am not sure if
broadcasting the challenges and/or authorizations may be a security
issue or if it may be too complicated for the client or server.
Consensus would have to be reached around one of the three identifier
options, some other way to include supported identifier info in the
directory, or excluding the supported identifier info from the
directory. Similar consensus would need to be reached for the
contacts.

Sincerely,

Logan Widick

---------- Forwarded message ----------
> From: Zach Shepherd <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Bcc:
> Date: Thu, 23 Mar 2017 18:06:04 +0000
> Subject: Re: [Acme] Allowing clients to understand the account creation functionality supported by a server
> Let's consider a simple world where all ACME servers support mailto and some ACME servers support tel.
>
> To create an account, the user provides the necessary information to their AMCE client: one or more email addresses and zero or more phone numbers. The ACME client then attempts to supply all of this information to in an account creation request. Some of the time, this will result in an error because the ACME server does not support tel.
>
> When the ACME client receives this error, it could:
> 1. Display it to the user and ask the user to adjust their input accordingly. (A poor user experience.)
> 2. Attempt to parse to the error message to confirm that the problem was the tel. (Hacky.)
> 3. Assume that the problem was the tel and retry without that. (Very hacky.)
>
> A new ACME server could come along that requires at least one tel or that doesn't support mailto. As a result, ACME clients may chose to attempt #2 and/or #3 before falling back to #1.
>
> This means that ACME clients have one of six different behaviors (#1, #2, #3, #2 falling back to #1, #3 falling back to #1, #2 falling back to #3 falling back to #1), some of which add a non-trivial amount of complexity to attempt to parse error messages (yuck.) and some of which end up pushing the complexity onto the end-user in end anyways. (Or worse, ACME clients wind up with hard-coded assumptions based on a specific ACME server implementation and become less portable.)
>
> Providing information about the supported contact schemes in a machine readable format (e.g., in response to a GET requests on the server's new-account URI) does add work for ACME server implementors, but not so much that it's worth complicating the end-user experience.
>
> Regards,
> Zach