Add support for did:ion

[awoie]

Add support for did:ion

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rado0x54]

https://identity.foundation/ion/

[rado0x54]

• Client Library: https://github.com/decentralized-identity/ion-tools#ionjs
• Blocked by the official release of MS Sidetree endpoint (protected by PoW Puzzle).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nklomp]

Just wanted to let you know we are working on creating a full implementation that supports recovery and updates, as well as generating keys on the fly and importing keys. It started out as a fork of this PR, as we need it for certain projects. But right now we need to have a fully working implementation soon. After the work in the URL is complete, we will create a PR to merge it into Veramo directly.

Next to the remaining work, there is a big issue currently with getting everything to work in React-Native. We had to fork several ION packages to get it to work. After the full implementation we will solve these ports in a nicer way as well.

If you are curious
https://github.com/Sphereon-Opensource/ssi-sdk/tree/feature/WAL-246/packages/ion-did-provider

[mirceanis]

That is wonderful news, and the implementation looks nice. Let us know how we can help.

I see you are defining. Some key relationships when importing them. We were thinking along the same lines but coming from the DID metadata angle (see #948). I like your approach too.
Also, we recently added support for full DID document updates, which might be suitable for the did:ion provider

[nklomp]

Thanks. The code still needs lots of cleanup a bit of refactoring and documentation, next to finishing the support to add services etc. Probably will be ready somewhere next week.

I do have some questions about Veramo and how to best address some issues:

ION uses a commit/reveal scheme for the updates. See an example payload below. Ideally you would be able to replace the update key in between invocations. The other solution is to add nonces to the JWKs for the same public key.

So either I would submit the payload using an new update Key (and thus JWK) and the current update Key. After success remove the current update Key from the Veramo KMS and store the new update Key. Or I would store nonces with the update Key. Using the current nonce to regenerate the JWK of the previous commitment and then a new nonce for the next update.

I am a bit worried that if the ION request somehow doesn't get anchored, I would loose the capability of updating since the keys or JWKs have been replaced. Is there a way to have something like versioning for Keys? Right now I would store the updateKeys with a version number in the KMS and a relationship denoting it was an update key. Then I would take the latest version. If I would be using different JWKs, which I will probably go for first, I would create a list of nonces in the metadata of the key. By default use the latest nonce to regenerate the current commitment, if that does not match the on chain commitment go up in the list of nonces to get to a matching commitment and delete the later commitments in case the current time offset is big enough versus the actual anchor time.

So for JWKs I have a reasonable easy approach. Ideally I would however rotate the full update key. Do you have a suggestion how to do that best in Veramo?

Example ION payload

const updateOperation = {
      operation: 'update',
      previous: {
        update: {
          // NOTE: This needs to be the 'previous' update key, or if the same key is being-reused the previous nonce to generate the JWK
          publicJwk: updateKey?.publicKeyJwk,
        },
      },
      update: {
          // NOTE: This needs to be the 'new/current' update key, or if the same key is being-reused the new/update nonce to generate the JWK
        publicJwk: updateKey?.publicKeyJwk,
      },
      content: {
        addPublicKeys: [
          {
            ...this.createIonPublicKey(key, [VerificationRelationship.capabilityDelegation]),
          }
        ],
      },
}

[nklomp]

Another thing I noticed only recently.

You can set a kid when importing keys into Veramo, but you cannot define a kid when Veramo generates a key for you.
I think it might be useful to be able to provide an optional kid for generation as well.
Current ION provider code basically does it's own generation if an existing key is not provided and then always import the keys.
We want the DIDs to work with imported keys and newly generated keys.

We had to create our own keys because we thought we needed access to the private key, but it seems we can work with the sign method from Veramo successfully against ION. So generating our own keys now only is required to be able to assign KIDs upfront for newly created keys. If Veramo would support KIDs upfront for to be generated keys, like it does during import of an existing key, we can remove if altogether from the ION provider.

see: https://github.com/Sphereon-Opensource/ssi-sdk/blob/760f456453494b824c2d7a95fe2b7c06494f01c8/packages/ion-did-provider/src/ion-did-provider.ts#L218

[nklomp]

PR for the new implementation can be found here: #987

[nklomp]

Created a ticket for the update issue with Microsoft's nodes in #1019.