On 11/15/2016 06:43 AM, Richard Barnes wrote: > 1. Removing the "requirements" abstraction and replacing the > "requirements" array with an "authorizations" array > 2. In particular, remove the OOB requirement type Seems good. > 3. "Inline" the authorization objects into the order/application > object, just as challenges are inlined into authorizations (while > still keeping them addressable, as challenges are) I don't see the need for this, and actually think it's a negative. GETs are cheap for the client, especially with HTTP/2. Inlining like this means there are two ways for a client to check the status of an authorization: by polling the authz, or by polling the application / order. We've seen in Boulder that having two ways to do things leads to bugs, so I'd rather say you must poll the authorization.
Also, for orders with lots of authz's in them, polling the order object will be more expensive for the server than polling individual authzs, because each poll of the order object has to reconstruct a larger number of objects from the DB. When clients poll individual authzs, they only check each authz until it is done, then stop. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
