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 protected]";, "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 protected]> > To: "[email protected]" <[email protected]> > Cc: "[email protected]" <[email protected]> > 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 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
