search

IDunion / indy-did-resolver

Resolver for the did:indy method
Apache License 2.0
8 stars 7 forks source link

Ledger object resolution #11

Closed domwoe closed 2 years ago

domwoe commented 2 years ago

Implements #9 as far as it's possible with the current version of indy-node and indy-vdr. Supersedes #8

paulbastian commented 2 years ago

I've tested the current PR and the order in the didDoc is mixed up:

{
  "authentication": [
    "did:indy:idunion:BDrEcHc8Tb4Lb2VyQZWEDE#verkey"
  ],
  "id": "did:indy:idunion:BDrEcHc8Tb4Lb2VyQZWEDE",
  "verificationMethod": [
    {
      "controller": "did:indy:idunion:BDrEcHc8Tb4Lb2VyQZWEDE",
      "id": "did:indy:idunion:BDrEcHc8Tb4Lb2VyQZWEDE#verkey",
      "publicKeyBase58": "2HHAKDS8EZK5ZfgZTT7jJFjE5bqkZuFoUgHYAZLjFMbY",
      "type": "Ed25519VerificationKey2018"
    }
  ]
}
domwoe commented 2 years ago

I've tested the current PR and the order in the didDoc is mixed up:

Do we care about the ordering? For software it shouldn't matter, but I agree that it looks odd.

For the base diddoc, we could fix it by using a struct (as you did with DidDocumentJson) but I'm not sure if the order in the diddoc content would be preserved

c2bo commented 2 years ago

I tried changing the serde_json library to use the feature preserve_order to preserve ordering. This breaks indy-vdr though :/ I couldn't get cargo to work with two different featuresets for serde_json without breaking stuff - seems to not be supported currently by cargo? Is everyone fine with creating a (ordered) struct for the top level DID Document and accept that sub-parts will not be ordered for the time being?

paulbastian commented 2 years ago

shall we make a merge and address it later? I think there is no ad-hoc solution