Change:
Note that the requests may contain addition Headers, request data and URL parameters that are not specified here, these extra fields should <del> be ignored, though may be used by the server to determine whether to </del> <ins> be ignored, though may be used by the Server to determine whether to </ins> fulfill the requested issuance/redemption. 3. <del> A client SHOULD fetch the server configuration and current key </del> <ins> A Client SHOULD fetch the Server configuration and current public key </ins> commitments prior to performing issuance and redemption.  This configuration is accessible via a "CONFIG_ENDPOINT", either provided <del> by the server or by a global registry that provides consistency and </del> <ins> by the Server or by a global registry that provides consistency and </ins> anonymization guarantees. 3.1. <del> To ensure that a server isn't providing different views of their key material/commitments to different users, servers are expected to write their commitments to a verifiable data structure. </del> <ins> To ensure that a Server isn't providing different views of their public key material to different users, Servers are expected to write their commitments to a verifiable data structure. </ins> Using a verifiable log-backed map (verifiable-data-structures), the <del> server can publish their commitments to the log in a way that clients can detect when the server is attempting to provide a split-view of their key commitments to different clients. </del> <ins> Server can publish their commitments to the log in a way that Clients can detect when the Server is attempting to provide a split-view of their key commitments to different Clients. </ins> The key to the map is the "server_origin", with the value being: The addition to the log is made via a signed message to the log operator, which verifies the authenticity against a public key <del> associated with that server origin (either via the Web PKI or a out- of-band key). </del> <ins> associated with that Server origin (either via the Web PKI or a out- of-band key).  The signature should be computed under a long-term signing key that is associated with the Server identity. </ins> <del> The server SHOULD then store an inclusion proof of the current key </del> <ins> The Server SHOULD then store an inclusion proof of the current key </ins> commitment so that it can present it when delivering the key <del> commitment directly to the client or when the key commitment is being </del> <ins> commitment directly to the Client or when the key commitment is being </ins> delivered by a delegated party (other registries/preloaded configuration lists/etc). <del> The client can then perform a request for the key commitment against either the global registry or the server as described key-commitment. </del> <ins> The Client can then perform a request for the key commitment against either the global registry or the Server as described in key- commitment.  Note that the signature should be verified by the Client to ensure that the key material is owned by the Server.  This requires that the Client know the public verification key that is associated with the Server. </ins> <del> To avoid user segregation as a result of server configuration/ </del> <ins> To avoid user segregation as a result of Server configuration/ </ins> commitment rotation, the log operator SHOULD enforce limits on how many active commitments exist and how quickly the commitments are being rotated.  Clients SHOULD reject configurations/commitments that

Discussion:
cc NAME for review. Mainly just removing the interfaces that were previously present and using the API functions from the protocol directly. I've also changed some of the wording around the key registry, and replaced client -> Client and server -> Server. Let me know if there is anything that you think I've missed.
We currently have interfaces in the architecture document that lay out how messages should be sent and received. I think the architecture document should be solely focused on the building of the ecosystem in a way that maintains the utility of the privacy and security guarantees made by the protocol. The interfaces are mainly used by the HTTP API doc, and so I think this will be a better home for them.
I've removed the interfaces from the architecture doc () and used the protocol API directly in the HTTP doc ()