I'm basically with Richard here. I don't think that the change that Jacob suggests is disastrous but it also doesn't seem very well-motivated and given that we're trying to get to done, the bar for changes like this should be fairly high. I don't think this rises to it.
On Sat, Oct 29, 2016 at 9:59 AM, Richard Barnes <[email protected]> wrote: > > > 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 > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
