diff --git a/fep/ae97/fep-ae97.md b/fep/ae97/fep-ae97.md
index c40ee7b..a7256d9 100644
--- a/fep/ae97/fep-ae97.md
+++ b/fep/ae97/fep-ae97.md
@@ -51,15 +51,19 @@ sequenceDiagram
   Client ->> Server: POST Update(Actor) to outbox
 ```
 
-Client creates portable actor objects according to [FEP-ef61] and stores them. When a portable actor is created, the client MUST create a key for signing requests (the main actor key) and add a `Multikey` representation of it to the `assertionMethod` array as described in [FEP-521a]. The identifier of that key MUST NOT be a [compatible identifier][CompatibleIdentifiers].
+Client creates portable actor objects according to [FEP-ef61] and stores them. When a portable actor is created, the client MUST create a key for signing HTTP requests (the main actor key) and add a `Multikey` representation of the correspondng public key to the `assertionMethod` array as described in [FEP-521a]. The identifier of that key MUST NOT be a [compatible identifier][CompatibleIdentifiers].
 
 Before registering a portable actor on the server, the client MUST add the server URL to the `gateways` array of the actor object.
 
-To register the actor, the client sends an HTTP POST request to the gateway endpoint at `/.well-known/apgateway` path. The body of the request MUST be an actor object.
+To register the actor, the client sends an HTTP POST request to the gateway endpoint at `/.well-known/apgateway` path. The body of the request MUST be the actor object.
 
-The server SHOULD limit registrations (for example, by requiring an invite code). If the server accepts the registration request, it generates an RSA key and returns it in a response. The response MUST have the `201 Created` status code. The body of the response is a JSON object with an `assertionMethod` property. The value of this property is an array containing the RSA public key generated by the server in the [Multikey][CI-Multikey] format.
+The server SHOULD limit registrations (for example, by requiring an invite code).
 
-Example:
+If the server accepts the registration request, it generates its own signing keys and returns the corresponding public keys in a response. The response MUST have a `201 Created` status code. The body of the response is a JSON object with an `assertionMethod` property. The value of this property is an array containing the public keys generated by the server in the [Multikey][CI-Multikey] format.
+
+At a minimum, the server SHOULD provide an RSA key, because other signature types are not widely supported in Fediverse.
+
+Example or a response:
 
 ```json
 {
@@ -90,7 +94,7 @@ The client submits signed [FEP-ef61] activities to actor's outbox. Contrary to w
 
 If activity contains a wrapped object (as in `Create` and `Update` activities), it MUST be a portable object created according to [FEP-ef61]. The server MUST validate object IDs in the same way it validates activity IDs.
 
-The server MUST deliver activities to their indended audiences without altering them. When signing HTTP requests, the server uses the RSA key generated during the registration.
+The server MUST deliver activities to their intended audiences without altering them. When signing HTTP requests, the server uses the RSA key generated during the registration.
 
 If the owner of the outbox is not registered, the server MUST return a `404 Not Found` status code.
 
@@ -150,7 +154,7 @@ If the media file doesn't exist or not owned by the actor, the server MUST retur
 If the server accepts portable objects with [compatible identifiers][CompatibleIdentifiers], it MUST ensure that all objects served by the gateway are valid and that registered actors are sufficiently isolated from each other. Specifically, the server MUST verify that actors and activities generated by the client are permitted in the [origin-based security model][FEP-fe34]:
 
 - Objects MUST NOT represent any actions that actors are not authorized to perform.
-- Objects MUST NOT represent server-controlled public keys or verification methods. Such objects can be identifed using the algorithm from [FEP-2277].
+- Objects MUST NOT represent server-controlled public keys or verification methods. Such objects can be identified using the algorithm from [FEP-2277].
 
 Precautions need also be taken when objects with compatible IDs are delivered to inboxes or fetched from remote servers.