Merge branch 'main' into devcontainer-acapy-version

aries_cloudagent/revocation/routes.py

@@ -888,7 +888,7 @@ async def update_rev_reg_revoked_state(request: web.BaseRequest):
             available_write_ledgers = await ledger_manager.get_write_ledgers()
             LOGGER.debug(f"available write_ledgers = {available_write_ledgers}")
             LOGGER.debug(f"write_ledger = {write_ledger}")
-            pool = write_ledger[1].pool
+            pool = write_ledger.pool
             LOGGER.debug(f"write_ledger pool = {pool}")
 
             genesis_transactions = pool.genesis_txns

aries_cloudagent/tails/indy_tails_server.py

@@ -47,7 +47,7 @@ async def upload_tails_file(
             available_write_ledgers = await ledger_manager.get_write_ledgers()
             LOGGER.debug(f"available write_ledgers = {available_write_ledgers}")
             LOGGER.debug(f"write_ledger = {write_ledger}")
-            pool = write_ledger[1].pool
+            pool = write_ledger.pool
             LOGGER.debug(f"write_ledger pool = {pool}")
 
             genesis_transactions = pool.genesis_txns

docs/GettingStartedAriesDev/CredentialRevocation.md

@@ -246,7 +246,7 @@ thread ID and comment is emitted to registered webhook urls.
 
 ## Manually Creating Revocation Registries
 
-> NOTE: This capability is deprecated and will likely be removed entirely in an upcoming release of ACA-Py. 
+> NOTE: This capability is deprecated and will likely be removed entirely in an upcoming release of ACA-Py.
 
 The process for creating revocation registries is completely automated - when you create a Credential Definition with revocation enabled, a revocation registry is automatically created (in fact 2 registries are created), and when a registry fills up, a new one is automatically created.
 
@@ -276,14 +276,16 @@ There are several endpoints that must be called, and they must be called in this
 
    - the tails server will check that the registry definition is already written to the ledger
 
-## Revocation Registry Rotation
+5. Post the initial accumulator value to the ledger `POST /revocation/registry/{rev_reg_id}/entry`
 
-From time to time an Issuer may want to issue credentials from a new Revocation Registry. That can be done by changing the Credential Definition, but that could impact verifiers. 
-Revocation Registries go through a series of state changes: `init`, `generated`, `posted`, `active`, `full`, `decommissioned`. When issuing revocable credentials, the work is done with the `active` registry record. There are always 2 `active` registry records: one for tracking revocation until it is full, and the second to act as a "hot swap" in case issuance is done when the primary is full and being replaced. This ensures that there is always an `active` registry. When rotating, all registry records (except records in `init` state) are `decommissioned` and a new pair of `active` registry records are created.  
-  
-Issuers can rotate their Credential Definition Revocation Registry records with a simple call: `POST /revocation/active-registry/{cred_def_id}/rotate`
+   - if you are an author (i.e. have a DID with restricted ledger write access) then this transaction may need to go through an endorser
+   - this operation **MUST** be performed on the the new revoc registry def **BEFORE** any revocation operations are performed
 
-It is advised that Issuers ensure the active registry is ready by calling `GET /revocation/active-registry/{cred_def_id}` after rotation and before issuance (if possible).
+## Revocation Registry Rotation
 
+From time to time an Issuer may want to issue credentials from a new Revocation Registry. That can be done by changing the Credential Definition, but that could impact verifiers.
+Revocation Registries go through a series of state changes: `init`, `generated`, `posted`, `active`, `full`, `decommissioned`. When issuing revocable credentials, the work is done with the `active` registry record. There are always 2 `active` registry records: one for tracking revocation until it is full, and the second to act as a "hot swap" in case issuance is done when the primary is full and being replaced. This ensures that there is always an `active` registry. When rotating, all registry records (except records in `init` state) are `decommissioned` and a new pair of `active` registry records are created.
 
+Issuers can rotate their Credential Definition Revocation Registry records with a simple call: `POST /revocation/active-registry/{cred_def_id}/rotate`
 
+It is advised that Issuers ensure the active registry is ready by calling `GET /revocation/active-registry/{cred_def_id}` after rotation and before issuance (if possible).