Upgrade IDIM Issuers to ACA-Py v0.10.2 and Askar only images. #109

WadeBarnes · 2023-08-31T21:17:35Z

DEV
- Rotate RevReg: cred_def_id XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV
SIT - Before September 6th
- Rotate RevReg: cred_def_id 7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT
QA - Before September 6th
- Rotate RevReg: cred_def_id KCxVC8GkKywjhWJnUfCmkW:3:CL:20:PersonQA
Prod - September 28th
- Rotate RevReg: cred_def_id RGjWbW1eycP7FrMf4QJvX8:3:CL:13:Person

Related task:

Rotate IDIM revocation registries #103

The text was updated successfully, but these errors were encountered:

WadeBarnes · 2023-08-31T21:31:19Z

Response from /revocation/active-registry/XpgeQa93eZvGSZBZef3PHn%3A3%3ACL%3A28075%3APersonDEV/rotate for dev:

{
  "rev_reg_ids": [
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:d3f96e1c-951a-4a9b-9d31-6a6d921ee0c8",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:1b6373a4-3200-4cbd-89c2-0984283e50f9"
  ]
}

WadeBarnes · 2023-09-01T12:52:38Z

Response from /revocation/active-registry/XpgeQa93eZvGSZBZef3PHn%3A3%3ACL%3A28075%3APersonDEV/rotate for sit:

{
  "rev_reg_ids": [
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:50205010-00ae-4e47-b513-4ded5df05727",
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:6b8710bb-79c8-4846-b257-378853336abf"
  ]
}

WadeBarnes · 2023-09-01T13:00:54Z

Response from /revocation/active-registry/XpgeQa93eZvGSZBZef3PHn%3A3%3ACL%3A28075%3APersonDEV/rotate for qa:

{
  "rev_reg_ids": [
    "KCxVC8GkKywjhWJnUfCmkW:4:KCxVC8GkKywjhWJnUfCmkW:3:CL:20:PersonQA:CL_ACCUM:b8ada6b0-c3c6-4e26-bb52-3b1aa9bef1b8",
    "KCxVC8GkKywjhWJnUfCmkW:4:KCxVC8GkKywjhWJnUfCmkW:3:CL:20:PersonQA:CL_ACCUM:921ca010-04e7-4667-b613-5037e0459551"
  ]
}

usingtechnology · 2023-09-06T19:41:55Z

do we know the states of the registries (that are failing)?

if they are state=="init" nothing happens, and if they are not "active", then a new registry isn't created.

WadeBarnes · 2023-09-06T19:47:11Z

Where would I get that info?

usingtechnology · 2023-09-06T19:48:36Z

Try: GET /revocation/registry/{rev_reg_id}

WadeBarnes · 2023-09-06T19:50:24Z

dev - both "state": "decommissioned":

https://candyscan.idlab.org/txs/CANDY_DEV/domain?page=1&pageSize=50&filterTxNames=[]&sortFromRecent=true&search=XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV

{
  "rev_reg_ids": [
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:d3f96e1c-951a-4a9b-9d31-6a6d921ee0c8",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:1b6373a4-3200-4cbd-89c2-0984283e50f9"
  ]
}

sit - both "state": "decommissioned":

https://candyscan.idlab.org/txs/CANDY_DEV/domain?page=1&pageSize=50&filterTxNames=[]&sortFromRecent=true&search=7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT

{
  "rev_reg_ids": [
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:50205010-00ae-4e47-b513-4ded5df05727",
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:6b8710bb-79c8-4846-b257-378853336abf"
  ]
}

qa - both "state": "decommissioned":

https://candyscan.idlab.org/txs/CANDY_TEST/domain?page=1&pageSize=50&filterTxNames=[]&sortFromRecent=true&search=KCxVC8GkKywjhWJnUfCmkW:3:CL:20:PersonQA

{
  "rev_reg_ids": [
    "KCxVC8GkKywjhWJnUfCmkW:4:KCxVC8GkKywjhWJnUfCmkW:3:CL:20:PersonQA:CL_ACCUM:b8ada6b0-c3c6-4e26-bb52-3b1aa9bef1b8",
    "KCxVC8GkKywjhWJnUfCmkW:4:KCxVC8GkKywjhWJnUfCmkW:3:CL:20:PersonQA:CL_ACCUM:921ca010-04e7-4667-b613-5037e0459551"
  ]
}

usingtechnology · 2023-09-06T19:53:43Z

Sigh, ok so they can get set to decommissioned and not kick off an init new registry. What we really need to know is (and I don't know how we could now...) is the state before the rotate call. It has to be "active" when you call rotate to kick off the init process.

WadeBarnes · 2023-09-06T19:55:16Z

They were active before the rotate call. All were being actively used to issue and revoke credentials.

swcurran · 2023-09-06T19:56:27Z

Looks to me like the RevReg rotation didn’t work. I don’t see any new RevRegDefs on CandyScan Dev, where the DIDs seem to be — not on Dev or SIT. It looks like the RevRegs were decommissioned, but the new RevRegDefs were not created.

swcurran · 2023-09-06T19:58:07Z

Link for SIT: https://candyscan.idlab.org/txs/CANDY_DEV/domain?page=1&pageSize=50&filterTxNames=[%22REVOC_REG_DEF%22]&sortFromRecent=true&search=7xjfawcnyTUcduWVysLww5

swcurran · 2023-09-06T20:01:08Z

They were active before the rotate call. All were being actively used to issue and revoke credentials.

That is the purpose of the rotate — to decommission the ones that were active, and to create new ones that become the active one. However, it looks like the creation step didn’t work in this execution.

usingtechnology · 2023-09-06T20:01:46Z

Well, someone put in a PATCH /revocation/registry/{rev_reg_id}/set-state?state=active API... it;s either that or create a new registry but don't think that's what you want?

I suppose if it doesn't get back to issuing then it will be POST /revocation/create-registry but that seems heavy handed.

usingtechnology · 2023-09-06T20:03:20Z

They were active before the rotate call. All were being actively used to issue and revoke credentials.

That is the purpose of the rotate — to decommission the ones that were active, and to create new ones that become the active one. However, it looks like the creation step didn’t work in this execution.

Yeah, the only thing I can see is that kicking off the "init" process is dependent on notifications on the event bus... which is the same no matter when it's created but any chance of a message being missed? 🤷

usingtechnology · 2023-09-06T20:05:25Z

They were active before the rotate call. All were being actively used to issue and revoke credentials.

That is the purpose of the rotate — to decommission the ones that were active, and to create new ones that become the active one. However, it looks like the creation step didn’t work in this execution.

Just to be clear, it will mark other registries as "decommissioned" but will only create/init a new one if the current state is active. So just because it is marked decommissioned after the call doesn't mean that it was active before the call.

WadeBarnes · 2023-09-06T20:07:04Z

I confirmed the state by looking at the state in the prod environment, which has not been rotated yet. All of the environments were identical, and the state in prod is active. So I'd expect that new RevRegs would have been created.

swcurran · 2023-09-06T20:10:19Z

Agree — they must have been active.

WadeBarnes · 2023-09-06T20:12:08Z

So the fix in this case is to create new registries manually using /revocation/create-registry; correct?

usingtechnology · 2023-09-06T20:12:11Z

I confirmed the state by looking at the state in the prod environment, which has not been rotated yet. All of the environments were identical, and the state in prod is active. SO I'd expect that new RevRegs would have been created.

OK, that sounds good and narrows it down... so more along the lines of what i put above and a hiccup on the notification...?

            init = IssuerRevRegRecord.STATE_ACTIVE == rec.state
            await self._set_registry_status(
                rec.revoc_reg_id, IssuerRevRegRecord.STATE_DECOMMISSIONED, init
            )

        if (state in IssuerRevRegRecord.TERMINAL_STATES) and init:
            return await self.init_issuer_registry(
                registry.cred_def_id,
                registry.max_cred_num,
                registry.revoc_def_type,
            )

terminal states are full and decommissioned, so if you pass in either of those AND that you want to init (prev state was active) then kick off the init process - which uses notifications and event bus.

WadeBarnes · 2023-09-06T20:17:08Z

Sorry, not sure what all that means.

usingtechnology · 2023-09-06T20:17:25Z

So the fix in this case is to create new registries manually using /revocation/create-registry; correct?

I think so. POST body is something like this:

{
  "credential_definition_id": cred_def_id, 
  "max_cred_num": 1000
}

usingtechnology · 2023-09-06T20:19:34Z

Sorry, not sure what all that means.

just showing the key parts of the logic on rotate... if they were active then init was true and it should have kicked off the init_issuer_registry... since they were active and we didn't get a new registry was just looking at points of failure. first thing I would think of is the notification didn't get pushed or received that does the work.

WadeBarnes · 2023-09-06T20:20:45Z

Ok, that covers the fix for our current situation. Do you want a ticket in ACA-Py for tracking the permanent fix? Would the fact that these agents are using an endorser service have anything to do with the new RevRegs not being created? i.e. messages not getting to the endorser?

swcurran · 2023-09-06T20:21:38Z

I hate to add more work, but can we back up DEV so we (might) have another try if this doesn’t work the first time? I think this is the right thing as well.

I think so. POST body is something like this:
{
  "credential_definition_id": cred_def_id, 
  "max_cred_num": 1000
}

swcurran · 2023-09-06T20:24:49Z

Ok, that covers the fix for our current situation. Do you want a ticket in ACA-Py for tracking the permanent fix? Would the fact that these agents are using an endorser service have anything to do with the new RevRegs not being created? i.e. messages not getting to the endorser?

Yes — we need an ACA-Py ticket. Nice to try it in the demo as the easiest way to verify the simple process works. We can even try with an Endorser there, I think.

WadeBarnes · 2023-09-06T20:25:32Z

I'll create a ticket and link to this ticket for the details.

usingtechnology · 2023-09-06T20:26:08Z

can we issue a few then rotate again? see if it repeatedly fails on dev?

so can you tell if the call didn't get to the endorser? or if the call didn't get back from the endorser? A lot of workflow creating the registry.

WadeBarnes · 2023-09-06T20:26:18Z

I hate to add more work, but can we back up DEV so we (might) have another try if this doesn’t work the first time? I think this is the right thing as well.
I think so. POST body is something like this:
{
  "credential_definition_id": cred_def_id, 
  "max_cred_num": 1000
}

A backup is not going to help much if things get written tot he ledger.

usingtechnology · 2023-09-08T15:44:18Z

active record is oldest published but not full.
there should be 2 active so we have an immediate fallover when we the working active is full.

WadeBarnes · 2023-09-08T15:47:06Z

Best way to decommission an unnecessary RevReg with /revocation/registry/{rev_reg_id}/set-state not understanding decommissioned would be to mark it as full; correct?

usingtechnology · 2023-09-08T15:53:31Z

that would be the way. just to be clear set-state does no additional processing.

WadeBarnes · 2023-09-08T15:59:22Z

OK, the idim-dev instance has been fixed. The 2 RevRegs that were created during the rotation have been successfully posted to the ledger and activated. The other one I created manually has been set to full.

Active:

{
  "rev_reg_ids": [
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:a57e7adb-a44c-4ccb-9af1-b50ce77673be",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:4a165d42-1215-41cd-b4dc-806855c37f1a"
  ]
}

Full:

{
  "rev_reg_ids": [
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:64293046-0895-403a-b695-6b3698e5f11b"
  ]
}

Decommisioned:

{
  "rev_reg_ids": [
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:1b6373a4-3200-4cbd-89c2-0984283e50f9",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:d3f96e1c-951a-4a9b-9d31-6a6d921ee0c8"
  ]
}

Ledger txns:

https://candyscan.idlab.org/txs/CANDY_DEV/domain?page=1&pageSize=50&filterTxNames=[%22REVOC_REG_DEF%22]&sortFromRecent=true&search=XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV

WadeBarnes · 2023-09-08T16:00:06Z

On to fix upgrade and fix the sit and qa instances.

usingtechnology · 2023-09-08T16:01:34Z

nice work @WadeBarnes !

WadeBarnes · 2023-09-08T16:13:39Z

nice work @WadeBarnes !

Thanks for the help!

WadeBarnes · 2023-09-08T17:54:15Z

IDIM is experiencing errors when publishing revocations to the new RegRegs. They are not having any issues publishing revocations to the decommissioned registry.

idim-dev-revoke-error.log

@marcos-carretero, @swcurran, @usingtechnology, @esune, @shaangill025

WadeBarnes · 2023-09-08T17:59:23Z

With the new RevRegs being published manually, is there a step that I could have missed? Does there need to be an initial RevRegEntry written to them?

WadeBarnes · 2023-09-08T18:00:39Z

I think I missed writing the tails file.

WadeBarnes · 2023-09-08T18:04:44Z

Tails files for the new registries have been published.

WadeBarnes · 2023-09-08T18:13:44Z

Wade Barnes @wade.barnes 11:01 AM
I think I missed writing the tails file. Looking.
Ok, try again. The tails files have been published.

Jay Cheng @jay.cheng 11:10 AM
I was able to revoke the credential issued earlier today; however, I issued another credential and getting http status 500 when revoking it
Timestamp would be around 11:07:50am

New log (time in UTC):
idim-dev-revoke-error.log

swcurran · 2023-09-08T19:13:16Z

Reviewing the log in detail — the first errors in the sequence are from webhooks failing. Those occur starting at 2023-09-08 18:07:49,424 to announce the completion of the issue-credential task. Then it looks like we get a Revocation Failure, and then an attempt to fix the revocation failure, which also fails.

Anyone know why the messages to the controller are failing? It would be nice to get that cleaned up so we know it is not an issue.

I think the attempt to fix the failure fails because the “fix” routine is not smart enough to handle the fixing a problem with the first publish revocation. It expects it will get the “prev_accum” from the latest RevRegEntry, but in this case it needs to get it from the RevRegDef. because the expected first RevRegEntry was never published. See the CandyScan entries for the two active RevRegs — there is no first RevRegEntry for them.

But that doesn’t solve why the RevRegEntry write fails in the first place.

There are also a bunch of errors at start up similiar to the DID Resolution fix from yesterday, but it appears that things proceed regardless. I’ll see if we can get those looked at.

swcurran · 2023-09-08T19:15:06Z

Ah…the messages back to the controller are failing as 400s. I bet that the controller is giving a 404 for the messages it is not prepared to receive/doesn’t care about. Which is probably fine. So I think we can safely ignore those.

swcurran · 2023-09-08T19:27:18Z

I think I know what is going on. The creation of a RevReg does two writes — the RevRegDef and the first RevRegEntry that happens (usually) 3 seconds later. You can look at CandyScan here to see that. If you look at the latest ledger entries. The RevRegDefs were created along - no RevRegEntry.

I think the fix is to try to rotate the RevRegs again. I hate that without really knowing, but I don’t see another option. Perhaps we take a database backup before...

My guess is the partial completion of the RevReg

2023-09-08 13:53:13,989 aries_cloudagent.admin.server DEBUG Match info: <MatchInfo {'rev_reg_id': 'XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:4a165d42-1215-41cd-b4dc-806855c37f1a'}: <ResourceRoute [PUT] <DynamicResource  /revocation/registry/{rev_reg_id}/fix-revocation-entry-state> -> <function update_rev_reg_revoked_state at 0x7f1ac1587dc0>>
2023-09-08 13:53:13,989 aries_cloudagent.admin.server DEBUG Body: None
2023-09-08 13:53:13,989 aries_cloudagent.revocation.routes DEBUG >>> apply_ledger_update_json = false
2023-09-08 13:53:14,031 aries_cloudagent.revocation.routes DEBUG available write_ledgers = ['CANdyDev']
2023-09-08 13:53:14,031 aries_cloudagent.revocation.routes DEBUG write_ledger = <aries_cloudagent.ledger.indy_vdr.IndyVdrLedger object at 0x7f1aba0a9970>
2023-09-08 13:53:14,031 aries_cloudagent.revocation.routes DEBUG write_ledger pool = <aries_cloudagent.ledger.indy_vdr.IndyVdrLedgerPool object at 0x7f1ac06b2a60>
2023-09-08 13:53:14,031 aries_cloudagent.ledger.indy_vdr DEBUG Opening the pool ledger
2023-09-08 13:53:14,477 aries_cloudagent.admin.server ERROR Handler error with exception: 'NoneType' object is not subscriptable

=================
Traceback (most recent call last):
  File "/home/aries/.local/lib/python3.9/site-packages/aries_cloudagent/revocation/routes.py", line 928, in update_rev_reg_revoked_state
    ) = await rev_manager.update_rev_reg_revoked_state(
  File "/home/aries/.local/lib/python3.9/site-packages/aries_cloudagent/revocation/manager.py", line 180, in update_rev_reg_revoked_state
    return await rev_reg_record.fix_ledger_entry(
  File "/home/aries/.local/lib/python3.9/site-packages/aries_cloudagent/revocation/models/issuer_rev_reg_record.py", line 369, in fix_ledger_entry
    (rev_reg_delta, _) = await ledger.get_revoc_reg_delta(self.revoc_reg_id)
  File "/home/aries/.local/lib/python3.9/site-packages/aries_cloudagent/ledger/indy_vdr.py", line 1066, in get_revoc_reg_delta
    "accum": response_value["accum_to"]["value"]["accum"],
TypeError: 'NoneType' object is not subscriptable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/aries/.local/lib/python3.9/site-packages/aries_cloudagent/admin/server.py", line 181, in ready_middleware
    return await handler(request)
  File "/home/aries/.local/lib/python3.9/site-packages/aries_cloudagent/admin/server.py", line 218, in debug_middleware
    return await handler(request)
  File "/home/aries/.local/lib/python3.9/site-packages/aiohttp_apispec/middlewares.py", line 45, in validation_middleware
    return await handler(request)
  File "/home/aries/.local/lib/python3.9/site-packages/aries_cloudagent/admin/server.py", line 338, in check_token
    return await handler(request)
  File "/home/aries/.local/lib/python3.9/site-packages/aries_cloudagent/admin/server.py", line 450, in setup_context
    return await task
  File "/usr/local/lib/python3.9/asyncio/futures.py", line 284, in __await__
    yield self  # This tells Task to wait for completion.
  File "/usr/local/lib/python3.9/asyncio/tasks.py", line 328, in __wakeup
    future.result()
  File "/usr/local/lib/python3.9/asyncio/futures.py", line 201, in result
    raise self._exception
  File "/usr/local/lib/python3.9/asyncio/tasks.py", line 256, in __step
    result = coro.send(None)
  File "/home/aries/.local/lib/python3.9/site-packages/aries_cloudagent/revocation/routes.py", line 940, in update_rev_reg_revoked_state
    raise web.HTTPBadRequest(reason=str(err))
aiohttp.web_exceptions.HTTPBadRequest: 'NoneType' object is not subscriptable
2023-09-08 13:53:14,478 aiohttp.access INFO 10.97.6.1 [08/Sep/2023:13:53:13 +0000] "PUT /revocation/registry/XpgeQa93eZvGSZBZef3PHn%3A4%3AXpgeQa93eZvGSZBZef3PHn%3A3%3ACL%3A28075%3APersonDEV%3ACL_ACCUM%3A4a165d42-1215-41cd-b4dc-806855c37f1a/fix-revocation-entry-state?apply_ledger_update=false HTTP/1.1" 400 447 "https://idim-agent-admin-dev.apps.silver.devops.gov.bc.ca/api/doc" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36"

usingtechnology · 2023-09-08T19:49:49Z

hard to know which is empty/null/NoneType - response_value["accum_to"]["value"]["accum"]. could be either the accum_to or value.

WadeBarnes · 2023-09-11T13:33:14Z

I've confirmed the manual steps for creating the RevRegs is missing one final step, which is calling /revocation/registry/{rev_reg_id}/entry to post the initial accumulator value. I've also confirmed this is only possible when there are no revoked credentials, i.e. before any other operations. I'll submit a PR with the update to the docs.

I was able to post the initial RevRegEntry for the "backup" RevReg, but not for the "active" RegRev. That leaves the new RegRegs in a state where it's best to rotate them.

We can confirm this all again when I repair the sit environment.

WadeBarnes · 2023-09-11T13:45:35Z

After making a backup of the idim-dev wallet called /revocation/active-registry/{cred_def_id}/rotate. This time the rotation completed successfully; https://candyscan.idlab.org/txs/CANDY_DEV/domain?page=1&pageSize=50&filterTxNames=[%22REVOC_REG_DEF%22,%22REVOC_REG_ENTRY%22]&sortFromRecent=true&search=XpgeQa93eZvGSZBZef3PHn

Response from the call was:

{
  "rev_reg_ids": [
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:a57e7adb-a44c-4ccb-9af1-b50ce77673be",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:1b6373a4-3200-4cbd-89c2-0984283e50f9",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:d3f96e1c-951a-4a9b-9d31-6a6d921ee0c8",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:64293046-0895-403a-b695-6b3698e5f11b",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:4a165d42-1215-41cd-b4dc-806855c37f1a"
  ]
}

RevReg States for idim-dev:

Active:

{
  "rev_reg_ids": [
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:70093c2e-43f2-42fd-b376-5fd6b23a73b7",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:96fa823f-a320-4634-8708-b83ec0bddef2"
  ]
}

Decommissioned:

{
  "rev_reg_ids": [
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:a57e7adb-a44c-4ccb-9af1-b50ce77673be",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:1b6373a4-3200-4cbd-89c2-0984283e50f9",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:d3f96e1c-951a-4a9b-9d31-6a6d921ee0c8",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:64293046-0895-403a-b695-6b3698e5f11b",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:4a165d42-1215-41cd-b4dc-806855c37f1a"
  ]
}

So, the rotate set all of the previous RegRegs to decommissioned, including the one I had manually set to full. @usingtechnology, is that the expected behavior?

swcurran · 2023-09-11T13:48:15Z

Nice work! Yes — that is the expected behaviour of rotate. That specific behaviour was discussed and agreed to when the feature was implemented.

WadeBarnes · 2023-09-11T21:55:08Z

At IDIM's request I've rotated the RevRegs on the dev instance again.

Response:

{
  "rev_reg_ids": [
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:70093c2e-43f2-42fd-b376-5fd6b23a73b7",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:a57e7adb-a44c-4ccb-9af1-b50ce77673be",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:1b6373a4-3200-4cbd-89c2-0984283e50f9",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:96fa823f-a320-4634-8708-b83ec0bddef2",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:d3f96e1c-951a-4a9b-9d31-6a6d921ee0c8",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:64293046-0895-403a-b695-6b3698e5f11b",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:4a165d42-1215-41cd-b4dc-806855c37f1a"
  ]
}

State:

Active:

{
  "rev_reg_ids": [
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:998398da-fb47-4c31-958b-1d730a581638",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:1ae09ef3-acf7-4f3a-9a9b-f46374b82b21"
  ]
}

Decommissioned:

{
  "rev_reg_ids": [
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:70093c2e-43f2-42fd-b376-5fd6b23a73b7",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:a57e7adb-a44c-4ccb-9af1-b50ce77673be",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:1b6373a4-3200-4cbd-89c2-0984283e50f9",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:96fa823f-a320-4634-8708-b83ec0bddef2",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:d3f96e1c-951a-4a9b-9d31-6a6d921ee0c8",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:64293046-0895-403a-b695-6b3698e5f11b",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:4a165d42-1215-41cd-b4dc-806855c37f1a"
  ]
}

WadeBarnes · 2023-09-12T19:31:42Z

Fixing idim-sit.

Starting state of RevRegs for 7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT

Posted:

{
  "rev_reg_ids": [
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:ec28f7d7-23a0-474e-9f56-5c2fd3204d77",
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:a81d6e90-b2ee-42ef-b0d9-fa81ffa2f3b8"
  ]
}

Decommissioned:

{
  "rev_reg_ids": [
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:50205010-00ae-4e47-b513-4ded5df05727",
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:6b8710bb-79c8-4846-b257-378853336abf"
  ]
}

Steps to recover the RevRegs that were created during rotation, but not written to the ledger:

Upgrade ACA-Py instance; py3.9-0.10.2-rc0
Set state generated; PATCH /revocation/registry/{rev_reg_id}/set-state
Post to ledger (tails URL is already set); POST /revocation/registry/{rev_reg_id}/definition
Write tails file; PUT /revocation/registry/{rev_reg_id}/tails-file
Post initial RevRegEntry; POST /revocation/registry/{rev_reg_id}/entry

End state of RevRegs for 7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT

Active:

{
  "rev_reg_ids": [
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:ec28f7d7-23a0-474e-9f56-5c2fd3204d77",
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:a81d6e90-b2ee-42ef-b0d9-fa81ffa2f3b8"
  ]
}

Decommissioned:

{
  "rev_reg_ids": [
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:50205010-00ae-4e47-b513-4ded5df05727",
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:6b8710bb-79c8-4846-b257-378853336abf"
  ]
}

Registries:

WadeBarnes · 2023-09-14T18:01:24Z

At IDIM's request I've rotated the RevRegs on the sit instance.

/revocation/active-registry/7xjfawcnyTUcduWVysLww5%3A3%3ACL%3A28075%3APersonSIT/rotate

{
  "rev_reg_ids": [
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:ec28f7d7-23a0-474e-9f56-5c2fd3204d77",
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:a81d6e90-b2ee-42ef-b0d9-fa81ffa2f3b8",
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:50205010-00ae-4e47-b513-4ded5df05727",
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:6b8710bb-79c8-4846-b257-378853336abf"
  ]
}

Active:

{
  "rev_reg_ids": [
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:6280c6b5-36d3-419a-9e5b-0b1d993a9a8c",
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:0e75ecfc-da6c-4265-8f92-da3fa3611397"
  ]
}

Decommissioned:

{
  "rev_reg_ids": [
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:ec28f7d7-23a0-474e-9f56-5c2fd3204d77",
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:a81d6e90-b2ee-42ef-b0d9-fa81ffa2f3b8",
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:50205010-00ae-4e47-b513-4ded5df05727",
    "7xjfawcnyTUcduWVysLww5:4:7xjfawcnyTUcduWVysLww5:3:CL:28075:PersonSIT:CL_ACCUM:6b8710bb-79c8-4846-b257-378853336abf"
  ]
}

Txns for the new Registries:

WadeBarnes · 2023-09-20T18:49:09Z

IDIM reported testing was successful.

WadeBarnes · 2023-09-25T12:24:44Z

Agents have been upgraded to ACA-Py 0.10.2 using; the py3.9-0.10.2 image:

dev
sit
qa

The initial set of rotated RevRegs for KCxVC8GkKywjhWJnUfCmkW:3:CL:20:PersonQA have been recovered.

Active:

{
  "rev_reg_ids": [
    "KCxVC8GkKywjhWJnUfCmkW:4:KCxVC8GkKywjhWJnUfCmkW:3:CL:20:PersonQA:CL_ACCUM:351f78c4-27c1-44a0-a83d-5bea7d397ec8",
    "KCxVC8GkKywjhWJnUfCmkW:4:KCxVC8GkKywjhWJnUfCmkW:3:CL:20:PersonQA:CL_ACCUM:f0a718ef-af17-4360-a76c-649861de56b7"
  ]
}

Decommissioned:

{
  "rev_reg_ids": [
    "KCxVC8GkKywjhWJnUfCmkW:4:KCxVC8GkKywjhWJnUfCmkW:3:CL:20:PersonQA:CL_ACCUM:921ca010-04e7-4667-b613-5037e0459551",
    "KCxVC8GkKywjhWJnUfCmkW:4:KCxVC8GkKywjhWJnUfCmkW:3:CL:20:PersonQA:CL_ACCUM:b8ada6b0-c3c6-4e26-bb52-3b1aa9bef1b8"
  ]
}

WadeBarnes · 2023-09-28T12:20:07Z

The IDIM prod agent has been upgraded to ACA-Py 0.10.2 using the py3.9-0.10.2 image, and the RevRegs have been rotated.

Active:

{
  "rev_reg_ids": [
    "RGjWbW1eycP7FrMf4QJvX8:4:RGjWbW1eycP7FrMf4QJvX8:3:CL:13:Person:CL_ACCUM:f954f297-07cd-444a-ba9b-96a126297ef2",
    "RGjWbW1eycP7FrMf4QJvX8:4:RGjWbW1eycP7FrMf4QJvX8:3:CL:13:Person:CL_ACCUM:0747da7c-1d0b-489e-aa84-9e94609e8174"
  ]
}

Decommissioned:

{
  "rev_reg_ids": [
    "RGjWbW1eycP7FrMf4QJvX8:4:RGjWbW1eycP7FrMf4QJvX8:3:CL:13:Person:CL_ACCUM:6a1fa86a-f5b2-4b26-ac94-ae165a63da10",
    "RGjWbW1eycP7FrMf4QJvX8:4:RGjWbW1eycP7FrMf4QJvX8:3:CL:13:Person:CL_ACCUM:badc49aa-6666-4a44-b375-060353258d0b"
  ]
}

WadeBarnes · 2023-09-28T12:24:55Z

This is finally complete

WadeBarnes self-assigned this Aug 31, 2023

WadeBarnes mentioned this issue Aug 31, 2023

Rotate IDIM revocation registries #103

Closed

WadeBarnes mentioned this issue Sep 8, 2023

chore: Prepare ACA-Py Patch Release 0.10.2 openwallet-foundation/acapy#2479

Closed

WadeBarnes mentioned this issue Sep 11, 2023

Update steps for Manually Creating Revocation Registries openwallet-foundation/acapy#2491

Merged

WadeBarnes changed the title ~~Upgrade IDIM Issuers to ACA-Py v0.10.1 and Askar only images.~~ Upgrade IDIM Issuers to ACA-Py v0.10.2 and Askar only images. Sep 28, 2023

WadeBarnes closed this as completed Sep 28, 2023

Upgrade IDIM Issuers to ACA-Py v0.10.2 and Askar only images. #109

Upgrade IDIM Issuers to ACA-Py v0.10.2 and Askar only images. #109

Comments

WadeBarnes commented Aug 31, 2023 • edited Loading

WadeBarnes commented Aug 31, 2023

WadeBarnes commented Sep 1, 2023

WadeBarnes commented Sep 1, 2023

usingtechnology commented Sep 6, 2023

WadeBarnes commented Sep 6, 2023

usingtechnology commented Sep 6, 2023

WadeBarnes commented Sep 6, 2023 • edited Loading

usingtechnology commented Sep 6, 2023

WadeBarnes commented Sep 6, 2023

swcurran commented Sep 6, 2023

swcurran commented Sep 6, 2023

swcurran commented Sep 6, 2023

usingtechnology commented Sep 6, 2023

usingtechnology commented Sep 6, 2023

usingtechnology commented Sep 6, 2023

WadeBarnes commented Sep 6, 2023 • edited Loading

swcurran commented Sep 6, 2023

WadeBarnes commented Sep 6, 2023

usingtechnology commented Sep 6, 2023

WadeBarnes commented Sep 6, 2023

usingtechnology commented Sep 6, 2023

usingtechnology commented Sep 6, 2023

WadeBarnes commented Sep 6, 2023

swcurran commented Sep 6, 2023

swcurran commented Sep 6, 2023

WadeBarnes commented Sep 6, 2023

usingtechnology commented Sep 6, 2023

WadeBarnes commented Sep 6, 2023

usingtechnology commented Sep 8, 2023

WadeBarnes commented Sep 8, 2023 • edited Loading

usingtechnology commented Sep 8, 2023

WadeBarnes commented Sep 8, 2023 • edited Loading

WadeBarnes commented Sep 8, 2023

usingtechnology commented Sep 8, 2023

WadeBarnes commented Sep 8, 2023

WadeBarnes commented Sep 8, 2023 • edited Loading

WadeBarnes commented Sep 8, 2023

WadeBarnes commented Sep 8, 2023

WadeBarnes commented Sep 8, 2023

WadeBarnes commented Sep 8, 2023

swcurran commented Sep 8, 2023 • edited Loading

swcurran commented Sep 8, 2023

swcurran commented Sep 8, 2023

usingtechnology commented Sep 8, 2023

WadeBarnes commented Sep 11, 2023 • edited Loading

WadeBarnes commented Sep 11, 2023

swcurran commented Sep 11, 2023

WadeBarnes commented Sep 11, 2023

WadeBarnes commented Sep 12, 2023 • edited Loading

WadeBarnes commented Sep 14, 2023

WadeBarnes commented Sep 20, 2023

WadeBarnes commented Sep 25, 2023

WadeBarnes commented Sep 28, 2023 • edited Loading

WadeBarnes commented Sep 28, 2023

WadeBarnes commented Aug 31, 2023 •

edited

Loading

WadeBarnes commented Sep 6, 2023 •

edited

Loading

WadeBarnes commented Sep 6, 2023 •

edited

Loading

WadeBarnes commented Sep 8, 2023 •

edited

Loading

WadeBarnes commented Sep 8, 2023 •

edited

Loading

WadeBarnes commented Sep 8, 2023 •

edited

Loading

swcurran commented Sep 8, 2023 •

edited

Loading

WadeBarnes commented Sep 11, 2023 •

edited

Loading

WadeBarnes commented Sep 12, 2023 •

edited

Loading

WadeBarnes commented Sep 28, 2023 •

edited

Loading