On Fri, Oct 28, 2016 at 6:34 PM, Jacob Hoffman-Andrews <[email protected]> wrote:
> On 10/28/2016 03:18 PM, Richard Barnes wrote: > > I think the crux of our disagreement is actually above. You seem to > > be arguing that authz for different identifier types are as different > > from one another as OOB is from DNS-name. I'm saying that the > > identifier validation process is going to be the same for many > > different identifiers, so the "authorization" abstraction is meaningful. > Can you give an example of how they will be the same? The currently > defined dns-01, http-01, and tls-sni-02 challenges can only be used for > DNS identifiers. > Sure. As I said before, you'll use different sets of challenges, but the overall flow remains the same. Imagine an ACME client / server has a module that implements the challenge / validation logic for a challenge types. For an HTTP challenge, it things like make the HTTP challenge object, configure an HTTP server, do the HTTP requests. For a putative SMS-based challenge, it would generate the challenge object, and orchestrate the sending / responding-to of SMS messages. Then the flow from the server's perspective is: 1. On new-app requiring a new authz: 1.1. Query the list of challenge modules to see which support $IDENTIFIER 1.2. For each supported challenge type, construct a challenge object for $IDENTIFIER 1.3. Assemble the challenges into an authorization object 2. When the client responds to a challenge: 2.1. Call out to the module that generated the challenge 2.2. [[ module goes off and validates the challenge ]] 2.3. When the module has finished validating, update the authz with the results. None of that is dependent on the type of identifier being validated. This is a very clean abstraction boundary. You can see this with the simplicity of the API in rocket-skates; the above is exactly what it does. > The "oob" challenges can be used by what you propose currently fill the > "requirements" niche. Specifically, you would have an authorization of > type "oob", containing a single challenge of type "oob." > Now you're the one adding unnecessary levels of abstraction ;) --Richard
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
