On Fri, Oct 28, 2016 at 8:55 PM, Jacob Hoffman-Andrews <[email protected]> wrote:
> Let me put it a different way: Offering the same value in multiple > places is really bad API design. I'm trying to fix that. We could remove > the inlined authorization status, leaving the requirements with an > inline status. But while we're at it, why not give requirements their > own addressable URLs? And what, fundamentally, is different about > requirements vs authorizations? > Good, these are the right questions. I do think there's a clear set of concepts here: * Requirement == What you have to do to get *this* *particular* certificate issued * Authz == You must do one of N things to prove you control the identifier * Challenge == Do this to prove you control the identifier The current structure is basically a conjunctive normal form: App <= (Chall1 || Chall2) && (Chall3 || Chall4) && Req1 That is, there are two things that tell the client what to do, requirements and challenges. Authorizations allow the CA to offer groups of challenges "or"ed together. So if you wanted to simplify things, I guess the thing you would want to do is define a general "or" grouping. But I don't think even that's worthwhile at this point, given that (1) the specialization of the authz grouping means you don't have to repeat the identifier in each challenge, and (2) we have no other requirements that require such an "or" grouping right now. As far as addressable URLs, I don't have a strong objection, but I don't see any need for it. If future types of requirements want to be addressable, they can define pointers to addressable objects, like the authz does right now. --Richard
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
