The previous definition of requirements created an awkward extra level of indirection, with status defined both on requirements and authorizations. It also created another object type, increasing the complexity of the protocol.
It was added mainly to provide a concept of an "out-of-band" requirement that could be satisfied, for instance, by adding funds to an account. However, this concept fits very well within the existing authorization framework, if we tweak the definition of authorizations so that authorizations are not always for domain names. Instead, we specify a type field on the authorization object, which can be "DNSName" or any other server-defined value. We can use the existing Out-of-Band challenge type to convey a link for users to visit to, for instance, provide payment. For "DNSName" authorizations, the same constraints still hold - there is a defined DNS name, and the challenges apply to that specific name. Editorially, I wound up moving the section about verifying correct Punycode encoding to new-application, since that is where the check needs to happen. Pull request: https://github.com/ietf-wg-acme/acme/pull/195 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
