That's fair. The text should probably state something along the lines of "If the server has an existing authorization for the identifier, depending on server policy, the server may return a 200 (OK) response with the existing authorization URL in the Location header field and the existing JSON authorization object in the body."
It currently reads as not allowing reuse of existing authorization objects, and always creating a new pending object and returning 201. From: Jacob Hoffman-Andrews <[email protected]> Sent: Wednesday, January 3, 2024 8:29 PM To: Deb Cooley <[email protected]>; [email protected]; [email protected]; [email protected]; Owen Friel (ofriel) <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [Acme] [Technical Errata Reported] RFC8555 (5861) This overspecifies things. When someone requests to create a new authorization object (or requests to create a new order object that would necessitate creation of new authorization objects), it is up to server policy whether to reuse an existing authorization or not. For instance a server might have a policy of never reusing authorization objects (that is, doing validation from scratch every time), or it might have a policy of reusing only pending authorization objects, or only ones created in the last N hours or days. So I think we should not accept this errata as it stands.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
