On 08/09/2016 05:27 PM, Andrew Ayer wrote: > This means that clients can't rely on the server offering this > endpoint. Although there is a risk of half-baked implementations > assuming all servers support it, it seems unlikely that many would make > this mistake. All clients have to go through the new-app workflow > anyways, and it's easier to just let the server create authorizations for > you.
I disagree that the risk of half-baked clients. Experience shows that if something works, some clients will do it, and will break if it's not available. This is exacerbated by the fact that the new-authz flow most closely matches the flow currently implemented in Boulder and used by existing ACME clients. So the reasonable and safe thing for a client maintainer to do would be to keep using new-authz if Let's Encrypt continues to offer it. I think the only way to make sure the ecosystem of ACME clients is actually interoperable with servers that don't implement new-authz is for Let's Encrypt not to implement new-authz in its next API revision. Which is reasonable, but it means that EKR's issue goes unaddressed. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
