On 10/02/2016 07:46 AM, Richard Barnes wrote: > I'm worried that we're losing a lot of useful, clear semantics here in > order to save a few bytes. This misunderstands the intent of this change. I'm not trying to save bytes here, I'm trying to clarify the semantics by (a) having fewer distinct types of objects, and (b) having a single, canonical place for clients to check the status of things.
The current approach of inlining the status field, or even inlining the whole authorization as your propose, would reduce semantic clarity and potentially introduce adding bugs, for the sake of saving a request. Here's another way of looking at it: The "requirements" notion has a lot in common with authorizations, in particular the need to do an action, poll for ready status, and ensure that each one present in a set is satisfied. Why define an entirely separate type? Also: Why are they not individually addressable, when authorizations are? If we make them individually addressable, why not make them the same type of object? This will make it easier for clients to implement them. > However, I'm not really sure that even that is worthwhile. Consider > that authorizations can be re-usable for multiple applications; we > envisage clients being able to authorize a bunch of domains, then > issue certificates for arbitrary combinations. I don't see how my proposal conflicts with authorization reuse. The server chooses which authorizations to require for a new application. It can choose to reuse those that are reusable (dns-name) and generate a new one each time for those that are a per-issuance requirement (payments). > This PR also removes two important pieces of functionality: > - The generic OOB requirement type - Would need to be replaced by new > authorization types This is a good point, I'll re-introduce an OOB authorization type to satisfy this need. > - The ability of the protocol to cleanly support new identifier types; > instead of just defining a new identifier type and some challenges, > you need to copy / paste the whole definition of the dns-name challenge. I'm not sure what this means. There's no "dns-name challenge." There are a set of challenges that are valid for dns-name authorizations. If somone defines a new identifier type, say email address, the set of challenges that are valid for that identifier type will definitely be different. This PR actually clarifies that situation. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
