|
| 1 | +--- |
| 2 | +id: key-rotation |
| 3 | +title: Key Rotation |
| 4 | +sidebar_label: Key Rotation |
| 5 | +description: Learn how you can rotate keys in the issuer node |
| 6 | +keywords: |
| 7 | + - docs |
| 8 | + - privado id |
| 9 | + - issuer node |
| 10 | + - key rotation |
| 11 | + - key |
| 12 | + - auth core claim |
| 13 | + |
| 14 | +--- |
| 15 | + |
| 16 | +import useBaseUrl from '@docusaurus/useBaseUrl'; |
| 17 | +import Tabs from '@theme/Tabs'; |
| 18 | +import TabItem from '@theme/TabItem'; |
| 19 | + |
| 20 | +When an identity is created on the issuer node, a credential (also referred to as [authCoreClaim](https://docs.iden3.io/getting-started/claim/auth-claim/)) is generated to sign issued credentials. This authCoreClaim is tied to a babyjubjub-type private key, which is securely stored based on the issuer node's configuration. Supported storage options include local storage, vault, or AWS Secret Manager – [see Key Management Configuration](./issuer-configuration.md/#kms-configuration). |
| 21 | + |
| 22 | +## Features |
| 23 | + |
| 24 | +### Security |
| 25 | +- The issuer node supports key rotation, allowing you to replace an old key (authCoreClaim) with a new one without disrupting operations. |
| 26 | +- Key rotation minimizes the risk of compromised keys being misused, ensuring that the system remains secure over time. |
| 27 | + |
| 28 | +### Credential Invalidation |
| 29 | +- Revoking an authCoreClaim (via its revocation nonce) automatically invalidates all credentials associated with it |
| 30 | +- This eliminates the need to revoke each credential individually, saving time and effort while ensuring quick and effective security enforcement. |
| 31 | + |
| 32 | +:::note |
| 33 | +The first `authCoreClaim` assosiated with an identity has a revocation nonce set to `0`. If this nonce is revoked, all previously issued credentials will become invalid for verification through ZKProofs. Additionally, new credentials cannot be issued with the identity linked to the revoked authCoreClaim. |
| 34 | +::: |
| 35 | + |
| 36 | +In the sections below, we’ll walk through the process of creating new credentials (authCoreClaims) for an identity on the issuer node. |
| 37 | + |
| 38 | +## Creating a New Key |
| 39 | + |
| 40 | +The first step in creating a new authCoreClaim is to generate a babyjubjub-type private key. The issuer node provides an endpoint for this purpose: |
| 41 | + |
| 42 | +`/v2/identities/{identifier}/keys` [API Reference](https://issuer-node-core-api-demo.privado.id/#post-/v2/identities/-identifier-/keys) |
| 43 | + |
| 44 | +In the request body, specify that you want to create a babyjubjub-type key and provide a unique name for the key: |
| 45 | + |
| 46 | +```json |
| 47 | +{ |
| 48 | + "keyType": "babyjubJub", |
| 49 | + "name": "my-new-key" |
| 50 | +} |
| 51 | +``` |
| 52 | +The response will include a JSON payload similar to this: |
| 53 | + |
| 54 | +```json |
| 55 | +{ |
| 56 | + "id": "ZGlkOmlkZW4zOnBv..." |
| 57 | +} |
| 58 | +``` |
| 59 | +The returned `id` represents the newly created babyjubjub key, which you’ll need to reference when creating the new `authCoreClaim`. |
| 60 | + |
| 61 | +## Creating the Auth Core Claim |
| 62 | + |
| 63 | +To create a new authCoreClaim, call the following endpoint: |
| 64 | + |
| 65 | +`/v2/identities/-identifier-/create-auth-credential` [API Reference](https://issuer-node-core-api-demo.privado.id/#post-/v2/identities/-identifier-/create-auth-credential) |
| 66 | + |
| 67 | +Include a request body like the example below: |
| 68 | + |
| 69 | +```json |
| 70 | +{ |
| 71 | + "KeyID" : "{{id of the previously generated key}}", |
| 72 | + "expiration": 1829174400, // Expiration date (optional) |
| 73 | + "version": 1, // Version (optional) |
| 74 | + "revNonce": 100, // Revocation nonce (optional) |
| 75 | + "credentialStatusType": "Iden3commRevocationStatusV1.0" // Must be supported by the issuer node (optional, default: Iden3commRevocationStatusV1.0) |
| 76 | +} |
| 77 | +``` |
| 78 | +The response will return the ID of the newly created credential. This `id` can be used to retrieve and inspect the credential using the endpoint: |
| 79 | + |
| 80 | +`/v2/identities/-identifier-/credentials/-id-` [API Reference](https://issuer-node-core-api-demo.privado.id/#post-/v2/identities/-identifier-/credentials/-id-) |
| 81 | + |
| 82 | +The returned credential JSON will include a `vc` field containing a `credentialStatus` object as shown below: |
| 83 | + |
| 84 | +```json |
| 85 | +[...] |
| 86 | +"credentialStatus": { |
| 87 | + "id": "<https://issuer-node/v2/agent>", |
| 88 | + "revocationNonce": 100, |
| 89 | + "type": "Iden3commRevocationStatusV1.0" |
| 90 | +}, |
| 91 | +[...] |
| 92 | +``` |
| 93 | +:::note |
| 94 | +The revocation nonce must be a unique value (not 0 or any value already assigned to other authCoreClaims). Revoking a nonce will invalidate all credentials associated with it. If no revocation nonce is provided, the issuer node will automatically assign one for you. |
| 95 | +::: |
| 96 | + |
| 97 | +## Activating the New Auth Core Claim |
| 98 | + |
| 99 | +Once the new babyjubjub key and authCoreClaim are created, the issuer node’s state must be published on-chain for the authCoreClaim to become active. Use the following endpoint to publish the state: |
| 100 | + |
| 101 | +`/v2/identities/-identifier-/state/publish` [API Reference](https://issuer-node-core-api-demo.privado.id/#post-/v2/identities/-identifier-/state/publish) |
| 102 | + |
| 103 | +After the transaction is confirmed, the new authCoreClaim will be ready for use in issuing credentials. |
| 104 | + |
| 105 | +## How Does the Issuer Node Choose Which Auth Core Claim to Use? |
| 106 | + |
| 107 | +When issuing a new credential, the issuer node sequentially selects an `authCoreClaim` based on the order in which they were created. A claim is considered valid if it has been published on-chain and is not revoked. |
| 108 | + |
| 109 | +If you want to prevent the issuer node from using a specific authCoreClaim: |
| 110 | + |
| 111 | +1. Revoke the nonce associated with that authCoreClaim. |
| 112 | +2. Publish the updated state on-chain to ensure the changes take effect. |
| 113 | + |
| 114 | +This process ensures that only the desired authCoreClaims are available for signing new credentials while maintaining security and flexibility in credential issuance. |
0 commit comments