On 10/28/2016 03:59 PM, Richard Barnes wrote: > 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. This flow seems reasonable. Why would it be different for what is currently called a "requirement?"
> > > 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 ;) Nope, the "oob" challenge is already defined, and the "oob" authorization type is equivalent to what is currently called a "requirement." So I'm making better use of things we already define.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
