Description

When attempting to run my React Native application, I encountered a resolution error related to "multiformats/bases/base64" emanating from the "@decentralized-identity/ion-sdk" dependency.

Issue Details

Upon executing my React Native project, the following error message is displayed:

The error occurs when using the IonDid method from the SDK as shown in the code snippet below:

import { IonDid } from "@decentralized-identity/ion-sdk";

const did = await IonDid.computeDidUniqueSuffix({
    requestID: 2212
});

Steps to Reproduce

1. Install "@decentralized-identity/ion-sdk" using npm or yarn.
2. Import and utilize the SDK in a React Native project.
3. Use the IonDid method as shown in the code snippet above.
4. Run the project using the React Native CLI or through a platform like Expo.
5. Observe the aforementioned error message.

Expected Behavior

The expected behavior is for the application to resolve all modules and dependencies without issue and launch without encountering resolution errors related to "multiformats/bases/base64".

Actual Behavior

An error message is displayed, preventing the successful launch of the application:
Unable to resolve "multiformats/bases/base64" from "node_modules/@decentralized-identity/ion-sdk/dist/lib/IonKey.js"

hello ION-SDK team,

According to the https://identity.foundation/sidetree/spec/#jwk-nonce, is suggested we can implement a nonce that will introduce the randomness to the update commitment, so I'm wondering whether there is any implementation already support this nonce feature. Because we want to keep using the same public key to reduce the key management efforts.

[publicKey as any] in IonRequest.spec.ts
[publicKeyModel1 as any] in IonDid.spec.ts

Hello ion-sdk team,

recently I'm investigating the ION node for the did, and I set up a local ION node for bitcoin testnet, and already created a did did:ion:test:EiCFkH_vqMVByb8tF7Ab9BW3GI9a8NrJdAB1TirmdzJa3g, and I tried to deactivated it, so now it looks like this,

{
"@context": "https://w3id.org/did-resolution/v1",
"didDocument": {
"id": "did:ion:test:EiCFkH_vqMVByb8tF7Ab9BW3GI9a8NrJdAB1TirmdzJa3g",
"@context": [
"https://www.w3.org/ns/did/v1",
{
"@base": "did:ion:test:EiCFkH_vqMVByb8tF7Ab9BW3GI9a8NrJdAB1TirmdzJa3g"
}
]
},
"didDocumentMetadata": {
"method": {
"published": true
},
"canonicalId": "did:ion:test:EiCFkH_vqMVByb8tF7Ab9BW3GI9a8NrJdAB1TirmdzJa3g"
}
}

and then I use the ION-SDK IonRequest.createRecoverRequest to create a recover request, like this
the originDid is the record I stored after do the deactivate, it keeps the key pairs for recover and update, and I use the same key pair for the next update/recover.

const docKeyPair = await IonKey.generateEs256kDidDocumentKeyPair({
        id: 'updateKeyId1',
        purposes: [IonPublicKeyPurpose.Authentication]
    });
 let recoverRequest = await IonRequest.createRecoverRequest(
        {
            didSuffix: originDidRecord.didSuffix,
            recoveryPublicKey: originDidRecord.recover.publicKey,
            signer: LocalSigner.create(originDidRecord.recover.privateKey),
            nextRecoveryPublicKey: originDidRecord.recover.publicKey,
            nextUpdatePublicKey: originDidRecord.update.publicKey,
            document: {
                publicKeys: [
                    docKeyPair[0]
                ],
                services: [
                    {
                        id: 'local-node-1',
                        type: 'website',
                        serviceEndpoint: 'http://localhost:3000'
                    },
                ],
            },
        }
    )

after I send the request to localhost:3000/operations and seems everything is ok, and the transaction of the bitcoin testnet is confirmed https://www.blockchain.com/btc-testnet/tx/0d04522143c47a8d5f0d091219bd2fe19724249aa0df5fb4ca96c67d0eb10580,

and I can see the record in the mongodb operstaions collection about this did, it includes a recover record, but when I resolve it, it's still the same with the deactivated state which shown on the top of this issue.

I'm wondering there is a bug of the recover I passed something wrong when generating the recover request

Hello!

I'm working on a small service that resolves ION DIDs according to the sidetree spec to support a Verifiable Credentials implementation. I'm trying to avoid re-writing as much TS code as possible considering it seems like there's a lot of support out there with this (1) codebase and (2) the reference implementation at decentralized-identity/sidetree.

Is (2) a reference implementation for just a sidetree node and this codebase a reference implementation for a service that is interfacing with the ION system (i.e. a verifiable credential wallet application using ION for identity)? Generally, is there guidance/documentation on how a ION client developer like myself should approach such a task?

To be super concrete, here's a preliminary description of behavior I'm trying to implement:

import { resolveDid } from "./resolver"
import OperationGenerator from "@decentralized-identity/sidetree/dist/tests/generators/OperationGenerator"

describe("DID Resolution", () => {
  describe("when the DID is poorly constructed", () => {
    it("returns an error", () => {})
  })

  describe("when the DID is long-form", () => {
    describe("when the did is not found on the blockchain", () => {
      it("returns a DID document from the long-form DID", async () => {
        const didString = await OperationGenerator.generateLongFormDid()
        const resolvedDid = resolveDid(didString.longFormDid)

        expect(resolvedDid).toEqual("foo")
      })
    })
  })
  describe("when the DID is short-form", () => {
    it("returns the DID document if it is found on the blockchain", () => {})
    it("returns a not found response", () => {})
  })
})

Thank you so much for the assistance!

cc/ @thehenrytsai @isaacJChen

multihashes is deprecated

there are breaking changes encountered when trying to use multihashes with actively maintained libraries like uint8arrays

multihashes encourages users to migrate to multiformats

See: TBD54566975/dwn-sdk-js#385

See #20 (comment)

Attempted to use the id value of '#dwn' in the service entry when creating an DID instance using ion-tools, but it fails with the following error:

Error: IdNotUsingBase64UrlCharacterSet: Key ID '#dwn' is not a Base64URL string.

Was using #dwn as id because that's the example used in the DWN specification.

This bug was reported on ion-sdk, while it was ion-tools that was used, but I think the error is probably related to the SDK?

Hey!
Your library is using uri-js, which hasn't received updates in three years.

Would you be interested in a PR that would switch to an up-to-date fork toad-uri-js, which addresses garycourt/uri-js#96 and garycourt/uri-js#87, several transitive security issues with dependencies, and aims to address garycourt/uri-js#92?

In my did document, the initial key created was authorized for authentication.
I would like the key to also be valid for assertion, so I was curious how I would go about to update the document to add the key into the assertionMethod array?

If I look at this: https://github.com/decentralized-identity/ion-tools#generateoperationtype-contents-commit-async, I could use an update event, but after that I am confused if I should use the addPublicKeys object, where I would just use the same id (hence overwriting?) and specifying the purposes ( ['authentication', 'assertion']?),

or should I use updatePublicKey via this interface: https://github.com/decentralized-identity/ion-tools/blob/9c6572daf91cc59f4bd489eb51da261d2483c0be/ion.js/lib.js#L172. Is the shape of the key object the same in both cases? How do I configure to pass through this object path: op.previous.update.publicJwk?

Thanks