On 09/27/2016 12:26 AM, Hugo Landau wrote: >> For "DNSName" authorizations, the same constraints still hold - there is >> a defined DNS name, and the challenges apply to that specific name. > This looks good. Only a slight nitpick — the label "DNSName" seems > out-of-kilter with the naming convention used by the rest of the > standard. "dns-name" or "dnsName" would be more appropriate?
Good feedback, thanks. I've pushed a change. > We should also consider allowing people to use URIs, or some sort of > vendor-prefixed types for authorizations and challenges, to avoid > collisions. e.g. "http://example.ca/account-funding-01"; or > "vnd.exampleca.account-funding-01" or "ca.example.account-funding-01". This also makes sense. I think URIs make more sense, rather than defining a new namespace. And the URIs can contain more information about the type. What do other folks think? On 09/27/2016 12:57 AM, Alan Doherty wrote: > surely ToS status could be just another required-authorisation (whichever term becomes the new one) Actually an earlier version of the protocol suggested this, but it makes much more sense to think of ToS agreement as an account-level action rather than a request-level action. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
