You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to make sure this is resilient to Mishti being down and we can use the current system for a period of time until Mishti is full ready and has had a successful epoch (90 day period).
Summary
we will introduce the concept of epochs
the VC structure will be changed:
we'll replace the hash attribute with nullifiers which will contain an array of 2 hashes:
the 1st will be the active hash of the epoch
the 2nd will be the future hash (the active hash in the next epoch)
each epoch will use 2 private keys
active key.- will be used to sign VCs and onchain payloads and create the active hash
future key.- will be used to create the future hash. This key will become the active key in the next epoch.
the functionality which issues the VCs in the new format should not be enabled by default, but should require a feature flag which is off by default
feature flags will be configured both in embed and iam services
the configuration specific for this new feature should include the following env vars:
CURRENT_EPOCH_KEY
CURRENT_EPOCH_START_TIME - start time in iso format
NEXT_EPOCH_1_KEY
NEXT_EPOCH_1_START_TIME - start time in iso format
NEXT_EPOCH_2_KEY
NEXT_EPOCH_2_START_TIME - start time in iso format
GIVEN I am start / restart the iam or embed services
WHEN the service start
THEN they load the current and next epoch start date, end date and keys
AND I am able to claim the new credentials on the new /api/v0.0.0/verify endpoint
GIVEN the iam & embed services are running and we have 3 epoch configured (epoch 1 - current, epoch 2, epoch 3)
AND the end of the current epoch (and implicitly the start of the next epoch) is configured to be T
WHEN I make a request to /api/v0.0.0/verify before time T
THEN I get a VC signed with epoch 1 and hashes for epoch 1 and 2
AND WHEN I make a request to /api/v0.0.0/verify starting with time T
THEN I get a VC signed with epoch 2 and hashes for epoch 2 and 3
The text was updated successfully, but these errors were encountered:
This request affects the following components:
We need to make sure this is resilient to Mishti being down and we can use the current system for a period of time until Mishti is full ready and has had a successful epoch (90 day period).
Summary
hash
attribute withnullifiers
which will contain an array of 2 hashes:Depends on:
Acceptance criteria
GIVEN I am start / restart the iam or embed services
WHEN the service start
THEN they load the current and next epoch start date, end date and keys
AND I am able to claim the new credentials on the new
/api/v0.0.0/verify
endpointGIVEN the iam & embed services are running and we have 3 epoch configured (epoch 1 - current, epoch 2, epoch 3)
AND the end of the current epoch (and implicitly the start of the next epoch) is configured to be
T
WHEN I make a request to
/api/v0.0.0/verify
before timeT
THEN I get a VC signed with epoch 1 and hashes for epoch 1 and 2
AND WHEN I make a request to
/api/v0.0.0/verify
starting with timeT
THEN I get a VC signed with epoch 2 and hashes for epoch 2 and 3
The text was updated successfully, but these errors were encountered: