>The removed language is a non-normative statement of fact
You can't introduce a new authentication method in post-Last Call revisions, and claim they are non-significant simply because they are not formally normative.
> It seems like you're trying to get rid of a better option to maintain the appearance architectural purity.
Nope, this is not a matter of architectural purity. Capability URLs are a strictly weaker authentication method than the JWS-based POSTs used everywhere in the protocol. If you read the doc (https://www.w3.org/TR/capability-urls/), it's all about the risks involved and how they should only be used as a last resort. The language we had up to draft 13 made this very explicit: GETs are not authenticated.
It seems like this was introduced in response to the STAR group requesting that final certificates be made GETtable. This was a pretty tenuous claim anyhow: If most ACME servers require POST for certificates, STAR-shaped clients won't be able to interoperate with them. So if you feel like STAR needs some special way to authenticate GETs, with lower security requirements than ACME, let's punt that to the STAR spec. Certificate GETs in ACME can be a MUST POST like everything else, and STAR can declare a "gettable certificate" extension.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
