search

bcgov / DITP-DevOps

Digital Identity and Trust Program Team's DevOps Documentation Repository
Apache License 2.0
2 stars 5 forks source link

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

Closed WadeBarnes closed 11 months ago

WadeBarnes commented 1 year ago

Related task:

WadeBarnes commented 12 months ago

@WadeBarnes I've downloaded and scanned through the error log from the comment above. What is the result of GET /resolver/resolve/did:sov:4wvr7DC2XUtsHbpUpYaKvM?

{
  "did_document": {
    "@context": "https://w3id.org/did/v1",
    "id": "did:sov:4wvr7DC2XUtsHbpUpYaKvM",
    "authentication": [
      "did:sov:4wvr7DC2XUtsHbpUpYaKvM#1"
    ],
    "service": [
      {
        "id": "did:sov:4wvr7DC2XUtsHbpUpYaKvM#didcomm",
        "type": "did-communication",
        "priority": 0,
        "recipientKeys": [
          "did:sov:4wvr7DC2XUtsHbpUpYaKvM#1"
        ],
        "serviceEndpoint": "https://aries-endorser-agent-dev.apps.silver.devops.gov.bc.ca"
      },
      {
        "id": "did:sov:4wvr7DC2XUtsHbpUpYaKvM#didcomm",
        "type": "did-communication",
        "priority": 0,
        "recipientKeys": [
          "did:sov:4wvr7DC2XUtsHbpUpYaKvM#1"
        ],
        "serviceEndpoint": "wss://aries-endorser-agent-dev.apps.silver.devops.gov.bc.ca"
      }
    ],
    "verificationMethod": [
      {
        "id": "did:sov:4wvr7DC2XUtsHbpUpYaKvM#1",
        "type": "Ed25519VerificationKey2018",
        "controller": "did:sov:4wvr7DC2XUtsHbpUpYaKvM",
        "publicKeyBase58": "39msujHp1jPTPbWA5Ry9BnwGvbVw8WYGh8WYjoEryyQp"
      }
    ]
  },
  "metadata": {
    "resolver_type": "native",
    "resolver": "LegacyPeerDIDResolver",
    "retrieved_time": "2023-09-07T12:53:06Z",
    "duration": 42
  }
}
dbluhm commented 12 months ago

Shoot -- I should have caught this. The issue is the two service endpoints. The corrections from #2409 incorrectly assign the same ID for both. I'll open a PR to ACA-Py. @swcurran this will trigger a small cascade of things to correct this. I'll open an issue for this on ACA-Py.

WadeBarnes commented 12 months ago

As a result of the issues with ACA-Py 0.10.1 the IDIM agents have a number of decommissioned RevRegs which are written to the ledger, a number of posted RevRegs which never got posted to the ledger, and NO active RevRegs.

IDIM-Dev for example: All:

{
  "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"
  ]
}

Posted:

{
  "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:64293046-0895-403a-b695-6b3698e5f11b",
    "XpgeQa93eZvGSZBZef3PHn:4:XpgeQa93eZvGSZBZef3PHn:3:CL:28075:PersonDEV:CL_ACCUM:4a165d42-1215-41cd-b4dc-806855c37f1a"
  ]
}

Decommissioned:

{
  "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"
  ]
}

Is there a way to get the posted ones written to the ledger? If not, what is the recommended way to move forward with the RevReg rotation that was interrupted by 0.10.1? I understand the /revocation/active-registry/{cred_def_id}/rotate endpoint will not create and post new RevRegs unless there are active ones. Will it decommission the ones in the posted state?

Hoping to avoid the manual process of setting the state of the posted ones and creating new ones.

cc @usingtechnology, @swcurran, @esune

WadeBarnes commented 12 months ago

I'm looking at using /revocation/registry/{rev_reg_id}/set-state to set the RevReg states so I can try reposting the ones that were created and not written to the ledger during the rotation. I've tried to use /revocation/registry/{rev_reg_id}/set-state to set the state of the RevReg I manually created to decommissioned, but it does not accept that as a valid state; {"state": ["Must be one of: init, generated, posted, active, full."]}

esune commented 12 months ago

@usingtechnology would calling the /rotate endpoint take care of this for @WadeBarnes, instead of having to manually fix things?

usingtechnology commented 12 months ago

/rotate won't really help in this case. it will mark all as decommissioned but will not kick off a new registry process as there is no active reg to rotate out. I think @WadeBarnes setting the state is the first thing to try. if all is well then move on, but if it doesn't work, setting state to active then calling rotate should work.

WadeBarnes commented 12 months ago

@usingtechnology, With a "functional" setup the agent has two RevRegs written to the ledger the active state, yet when you call /revocation/active-registry/{cred_def_id} it only lists one. How does AAC-Py know which one to use, does it just pick one (the first), or do you need to explicitly tell it. If you need to tell it how is that done?

I want to confirm before I proceed with trying to post the RevRegs and activate them.

usingtechnology commented 12 months ago

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 commented 12 months ago

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 commented 12 months ago

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

WadeBarnes commented 12 months ago

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:

WadeBarnes commented 12 months ago

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

usingtechnology commented 12 months ago

nice work @WadeBarnes !

WadeBarnes commented 12 months ago

nice work @WadeBarnes !

Thanks for the help!

WadeBarnes commented 12 months ago

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 commented 12 months ago

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 commented 12 months ago

I think I missed writing the tails file.

WadeBarnes commented 12 months ago

Tails files for the new registries have been published.

WadeBarnes commented 12 months ago

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 commented 12 months ago

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 commented 12 months ago

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 commented 12 months ago

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 commented 12 months ago

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

WadeBarnes commented 12 months ago

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 commented 12 months ago

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 commented 12 months ago

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

WadeBarnes commented 12 months ago

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 commented 11 months ago

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:

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 commented 11 months ago

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 commented 11 months ago

IDIM reported testing was successful.

WadeBarnes commented 11 months ago

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

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 commented 11 months ago

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 commented 11 months ago

This is finally complete