Add activation key encryption - #61
Conversation
…ted union
- Add GET /providers/{provider}/environments/{environment}/activationKeyParameters
- Replace flat ActivationKey with oneOf discriminator (ActivationKeyV1, ActivationKeyV2)
- Add ActivationKeyEncryptedPayload schema for decrypted v2 inner contents
- Add GetActivationKeyParametersResponse with supportedVersions and encryption
- Add EncryptionParameters schema (publicKey, algorithm, keyFormat)
- Read-only endpoint only (no POST/DELETE/PATCH)
73d0574 to
0971219
Compare
| All versions share a common envelope containing `version` and | ||
| `destinationEnvironmentUri`. The remaining fields differ by version. | ||
| type: object | ||
| required: |
There was a problem hiding this comment.
For cleanliness, I'd suggest you just put the properties for version / destinationEnvironmentUri here instead of each oneof reference
properties:
version: ...
destinationEnvironmentUri: ...
oneOf:
- $ref: "$/V1"
- $ref: "$/V2"should work correctly because oneOf refs get merged in at the same depth as where the 'oneOf' is.
| description: |- | ||
| The PEM-encoded public key for encrypting activation key contents | ||
| destined for this environment. Rotated weekly; the environment accepts | ||
| keys encrypted with any of the 4 most recent public keys. |
There was a problem hiding this comment.
Maybe rotation frequency should actually be included as a parameter? Helps inform the caller how often they should be pulling a new key, assuming some providers want more frequent rotations.
| publicKey: | ||
| description: |- | ||
| The PEM-encoded public key for encrypting activation key contents | ||
| destined for this environment. Rotated weekly; the environment accepts |
There was a problem hiding this comment.
"Should" be rotated weekly?
Presumably a pair of providers can agree on their frequency based on security needs (either more or less). As part of the spec we recommend at least weekly and matches what we prefer.
| $ref: paths/environments.yaml#/OneEnvironment | ||
| /providers/{provider}/environments/{environment}/ConfirmActivationKey: | ||
| $ref: paths/environments.yaml#/ConfirmActivationKey | ||
| /providers/{provider}/environments/{environment}/activationKeyParameters: |
There was a problem hiding this comment.
Any reason to prefer a custom method instead of adding the parameters as attributes on the environment itself?
…ationKey base Address review feedback: declare the shared envelope properties on the ActivationKey base alongside oneOf, instead of repeating destinationEnvironmentUri in each variant. oneOf branches merge at the same depth, so V1/V2 still contribute their variant-specific fields. version retains its per-variant enum constraint in each branch for discrimination. Backward compatible with v1 keys.
…ording - Add optional nextRotationAt (UTC date-time) so callers know when to refetch the public key, instead of exposing a rotation-frequency parameter. - Soften publicKey rotation guidance: recommend at least weekly, but cadence is agreed between the two partners per their security needs.
Adds in a new API to fetch encryption/activation key parameters.
Designs a scheme for encrypted activation key processes.