treewide: Fix RPC_REQUEST_STANDARD_NAME and RPC_RESPONSE_STANDARD_NAME
Change-Id: I190ade92c04313961edd4787196568216d028ba8
Reviewed-on: https://review.monogon.dev/c/monogon/+/3818
Tested-by: Jenkins CI
Reviewed-by: Lorenz Brun <lorenz@monogon.tech>
diff --git a/metropolis/proto/api/aaa.proto b/metropolis/proto/api/aaa.proto
index faf6dda..4cdfa18 100644
--- a/metropolis/proto/api/aaa.proto
+++ b/metropolis/proto/api/aaa.proto
@@ -45,7 +45,7 @@
// channel opened from a given IP address or with a given existing TLS
// certificate), and some dependent on external systems (eg. SSO).
//
- // If the requested identity within the first EscrowFromClient is not
+ // If the requested identity within the first EscrowRequest is not
// defined, the server may:
//
// - Abort the connection immediately with an error about an unknown
@@ -146,7 +146,7 @@
// will lead to retrieving identities from with the same namespace of
// entities.
//
- rpc Escrow(stream EscrowFromClient) returns (stream EscrowFromServer) {
+ rpc Escrow(stream EscrowRequest) returns (stream EscrowResponse) {
option (metropolis.proto.ext.authorization) = {
// The AAA implementation performs its own checks as needed, so the
// RPC middleware should allow everything through.
@@ -155,9 +155,9 @@
}
}
-message EscrowFromClient {
+message EscrowRequest {
// Parameters used for the entirety of the escrow flow. These must be set
- // only during the first EscrowFromClient message, and are ignored in
+ // only during the first EscrowRequest message, and are ignored in
// further messages.
message Parameters {
// The requested identity name. This is currently opaque and not defined,
@@ -178,7 +178,7 @@
// Proofs. These should only be submitted by the client after the server
// requests them, but if they are submitted within the first
- // EscrowFromClientMessage they will be interpreted too. The problem with
+ // EscrowRequestMessage they will be interpreted too. The problem with
// ahead of time proofs is that different a proof request from the server
// might parametrize the request in a way that would elicit a different
// answer from the client, so care must be taken to ensure that the
@@ -193,7 +193,7 @@
Proofs proofs = 2;
}
-message EscrowFromServer {
+message EscrowResponse {
// A proof requested from the server. Within an Escrow RPC, proofs can be
// either 'needed' or 'fulfilled'. Each proof has a kind, and kinds within
// all proof requests (either needed or fulfilled) are unique.
@@ -209,7 +209,7 @@
KIND_REFRESH_CERTIFICATE = 1;
// The client needs to present a static, plaintext password/token.
// This can be fulfilled by setting
- // EscrowFromClient.proofs.plaintext_password.
+ // EscrowRequest.proofs.plaintext_password.
// If the client presents an invalid password, the Escrow RPC will
// fail.
KIND_PLAINTEXT_PASSWORD = 2;