FEP-ef61: Key management (#883)

- Added "Key management" section.
- Clarified text in "Authentication and authorization" section.
- Moved did:key requirements to "did:key" section.

Reviewed-on: https://codeberg.org/fediverse/fep/pulls/883

fep/ef61/fep-ef61.md

@@ -85,12 +85,14 @@ Implementers MUST support the [did:key] method. Other DID methods SHOULD NOT be
 >[!NOTE]
 >The following additional DID methods are being considered: [did:web](https://w3c-ccg.github.io/did-method-web/), [did:dns](https://danubetech.github.io/did-method-dns/), [did:webvh](https://identity.foundation/didwebvh/) (formerly `did:tdw`) and [did:fedi](https://arcanican.is/excerpts/did-method-fedi.html).
 
-To maintain backward compatibility with existing [ActivityPub][ActivityPub] implementations that rely on an origin-based security model and do not canonicalize IDs before comparison, implementers MUST generate DIDs using the base58-btc alphabet, even though the specification [allows both base58-btc and base64url][did:key-syntax]. Using both alphabets in practice could prevent such servers from recognizing that a post whose `attributedTo` value is `https://base64url.example/.well-known/apgateway/did:key:u7QGwDY2Tjn93PVFWWq02piP1NE9_XRlg-c8-jhJiDqKBDw/actor` belongs to `https://base58.example/.well-known/apgateway/did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/actor`.
-
 DID documents SHOULD contain Ed25519 public keys represented as verification methods with `Multikey` type (as defined in the [Controlled Identifiers][Multikey] specification).
 
 Any [DID URL][DID-URL] capabilities of a DID method MUST be ignored when working with 'ap' URIs.
 
+#### did:key
+
+`did:key` identifiers MUST be generated using the base58-btc alphabet, even though the specification [allows both base58-btc and base64url][did:key-syntax]. Using both alphabets in practice could prevent applications from recognizing that two 'ap' URIs with differently encoded authorities refer to the same resource.
+
 ## Portable objects
 
 Example of a portable object:
@@ -157,7 +159,7 @@ When working with portable objects, the server SHOULD treat 'ap' URIs as opaque
 Authentication and authorization are performed in accordance with [FEP-fe34] origin-based security model, but with two important differences:
 
 - Cryptographic origins are used. They are similar to web origins described in [RFC-6454] but computed using a different algorithm.
-- Authentication via fetching from an origin is not possible. The main authentication method is verification of a signature.
+- Authentication via fetching from an origin is not possible. The main authentication method is the verification of an integrity proof.
 
 The origin of an 'ap' URI is identical to the authority component of its canonical form (i.e. it is a DID without percent encoding).
 
@@ -170,6 +172,14 @@ The value of `verificationMethod` property of the proof MUST be a [DID URL][DID-
 >[!NOTE]
 >This document uses terms "actor", "activity", "collection" and "object" according to the classification given in [FEP-2277].
 
+### Key management
+
+There are different ways to manage secret keys used to secure portable objects:
+
+- Server-side signing: secret keys are managed by a server (gateway). Activities are generated and immediately signed by a server.
+- Delegated signing: secret keys are managed by a separate service. Activities are generated by a server, which calls a signing service and then adds integrity proofs to activities.
+- Client-side signing: secret keys are managed by a client. Activities are generated and signed by a client, which communicates with a server via [FEP-ae97] API.
+
 ## Portable actors
 
 One [DID subject][DID-Subject] can control multiple actors (which are differentiated by the path component of an 'ap' URI).