publicKey -> verifiactionMethod

"keyAgreement": ["#encryption-key-1"]
"authentication": ["#authentication-key-1"] --> rename to "assertionMethod"

What about key.type?

• These are the least well defined.
• Just poulate everything with "JsonWebKey2020" and don't use it.

windows 10
npm 15
i get this error

docker build -t health-wallet-demo .
[+] Building 1200.9s (8/13)
=> [internal] load build definition from Dockerfile 0.1s
=> => transferring dockerfile: 329B 0.1s
=> [internal] load .dockerignore 0.1s
=> => transferring context: 54B 0.0s
=> [internal] load metadata for docker.io/library/node:13 3.6s
=> [1/9] FROM docker.io/library/node:13@sha256:70d4fffcab39a1f9f7161d58e674ddcc56c7f0724196b68d52a87bab15cb4a04 561.7s
=> => resolve docker.io/library/node:13@sha256:70d4fffcab39a1f9f7161d58e674ddcc56c7f0724196b68d52a87bab15cb4a04 0.0s
=> => sha256:70d4fffcab39a1f9f7161d58e674ddcc56c7f0724196b68d52a87bab15cb4a04 1.21kB / 1.21kB 0.0s
=> => sha256:2b9604a36e4911d15d2916dac4f1d853e2da612e9bb77df1016f8a51b3e333a1 7.88kB / 7.88kB 0.0s
=> => sha256:1c6172af85ee14a8db5a3a51d406b768dfa94d196c06d0d06d591507cf8199f0 45.38MB / 45.38MB 199.6s
=> => sha256:b194b0e3c928807cfabf081055a117585ba5bf6697f65b2fede02225a5d73ad2 10.80MB / 10.80MB 56.4s
=> => sha256:1e8d7127072cdbaae1935656444c3ec2bef8882c8c14d459e3a92ca1dd313c28 2.21kB / 2.21kB 0.0s
=> => sha256:1f5ec00f35d5b2d1db6b8e925a3005c1a285365775028db0339903ddaeec4763 4.34MB / 4.34MB 33.1s
=> => sha256:93b1353672b6861da5f1b58b0eca02ec10373a25d2898bddafa1b4bae2271c55 50.08MB / 50.08MB 286.1s
=> => sha256:3d7f38db3cca2c74df9a146d8419f5bf79d79b18de9eaee6351dccde16ab1f4a 214.91MB / 214.91MB 552.7s
=> => sha256:21e102f9fe89a18627c0ce50945bd1e0a11d0fecd4800bbbd999944d3940efc6 4.16kB / 4.16kB 200.1s
=> => extracting sha256:1c6172af85ee14a8db5a3a51d406b768dfa94d196c06d0d06d591507cf8199f0 1.6s
=> => sha256:d5431b24825a3297da35afe3d32786e01ec3fe7a8d1685adf59f82138e916e10 34.44MB / 34.44MB 358.6s
=> => extracting sha256:b194b0e3c928807cfabf081055a117585ba5bf6697f65b2fede02225a5d73ad2 0.3s
=> => extracting sha256:1f5ec00f35d5b2d1db6b8e925a3005c1a285365775028db0339903ddaeec4763 0.1s
=> => sha256:f780e3352c1809c08a5e6e4168206425ce703018baae8d6efd8d18efb101405b 2.38MB / 2.38MB 301.5s
=> => extracting sha256:93b1353672b6861da5f1b58b0eca02ec10373a25d2898bddafa1b4bae2271c55 1.9s
=> => sha256:4d28937582d0e76cbe8ed78ed921823a349a8a0755f91e13648e7636c974b0b6 295B / 295B 303.3s
=> => extracting sha256:3d7f38db3cca2c74df9a146d8419f5bf79d79b18de9eaee6351dccde16ab1f4a 6.7s
=> => extracting sha256:21e102f9fe89a18627c0ce50945bd1e0a11d0fecd4800bbbd999944d3940efc6 0.0s
=> => extracting sha256:d5431b24825a3297da35afe3d32786e01ec3fe7a8d1685adf59f82138e916e10 1.5s
=> => extracting sha256:f780e3352c1809c08a5e6e4168206425ce703018baae8d6efd8d18efb101405b 0.1s
=> => extracting sha256:4d28937582d0e76cbe8ed78ed921823a349a8a0755f91e13648e7636c974b0b6 0.0s
=> [internal] load build context 0.4s
=> => transferring context: 1.14MB 0.3s
=> [2/9] WORKDIR /usr/src/app 0.8s
=> [3/9] COPY package.json package-lock.json ./ 0.0s
=> ERROR [4/9] RUN npm ci 634.7s

[4/9] RUN npm ci:
#8 634.6 npm ERR! cb() never called!
#8 634.6
#8 634.6 npm ERR! This is an error with npm itself. Please report this error at:
#8 634.6 npm ERR! https://npm.community
#8 634.7
#8 634.7 npm ERR! A complete log of this run can be found in:
#8 634.7 npm ERR! /root/.npm/_logs/2021-01-16T20_27_55_657Z-debug.log

executor failed running [/bin/sh -c npm ci]: exit code: 1

See smart-on-fhir/health-cards#122

Update as appropriate given the referenced pull request

As an alternative to extension-based.

Also need to review for alignment with smart-on-fhir/health-cards#12

https://github.com/microsoft-healthcare-madison/health-wallet-demo/blob/master/test/vcs.test.ts#L46 tests should reflect this.

Right now, multiple clients will clobber the DID associated with Patient/sample-123

Per smart-on-fhir/health-cards#24

• Report: one of my tests that hits https://dev.c19.cards/api/test/encrypt-for-did stopped working recently

The format for .well-known/did-configuration.json has differed significantly from the pre-1.0 release included in this example app to the current version of the spec.

Here's an example payload for the current spec:

{
  "@context": "https://identity.foundation/.well-known/did-configuration/v1",
  "linked_dids": [
    {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://identity.foundation/.well-known/did-configuration/v1"
      ],
      "issuer": "did:key:z6MkoTHsgNNrby8JzCNQ1iRLyW5QQ6R8Xuu6AA8igGrMVPUM",
      "issuanceDate": "2020-12-04T14:08:28-06:00",
      "expirationDate": "2025-12-04T14:08:28-06:00",
      "type": [
        "VerifiableCredential",
        "DomainLinkageCredential"
      ],
      "credentialSubject": {
        "id": "did:key:z6MkoTHsgNNrby8JzCNQ1iRLyW5QQ6R8Xuu6AA8igGrMVPUM",
        "origin": "https://identity.foundation"
      },
      "proof": {
        "type": "Ed25519Signature2018",
        "created": "2020-12-04T20:08:28.540Z",
        "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..D0eDhglCMEjxDV9f_SNxsuU-r3ZB9GR4vaM9TYbyV7yzs1WfdUyYO8rFZdedHbwQafYy8YOpJ1iJlkSmB4JaDQ",
        "proofPurpose": "assertionMethod",
        "verificationMethod": "did:key:z6MkoTHsgNNrby8JzCNQ1iRLyW5QQ6R8Xuu6AA8igGrMVPUM#z6MkoTHsgNNrby8JzCNQ1iRLyW5QQ6R8Xuu6AA8igGrMVPUM"
      }
    },
    "eyJhbGciOiJFZERTQSJ9.eyJleHAiOjE3NjQ4Nzg5MDgsImlzcyI6ImRpZDprZXk6ejZNa29USHNnTk5yYnk4SnpDTlExaVJMeVc1UVE2UjhYdXU2QUE4aWdHck1WUFVNIiwibmJmIjoxNjA3MTEyNTA4LCJzdWIiOiJkaWQ6a2V5Ono2TWtvVEhzZ05OcmJ5OEp6Q05RMWlSTHlXNVFRNlI4WHV1NkFBOGlnR3JNVlBVTSIsInZjIjp7IkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL3YxIiwiaHR0cHM6Ly9pZGVudGl0eS5mb3VuZGF0aW9uLy53ZWxsLWtub3duL2RpZC1jb25maWd1cmF0aW9uL3YxIl0sImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmtleTp6Nk1rb1RIc2dOTnJieThKekNOUTFpUkx5VzVRUTZSOFh1dTZBQThpZ0dyTVZQVU0iLCJvcmlnaW4iOiJpZGVudGl0eS5mb3VuZGF0aW9uIn0sImV4cGlyYXRpb25EYXRlIjoiMjAyNS0xMi0wNFQxNDowODoyOC0wNjowMCIsImlzc3VhbmNlRGF0ZSI6IjIwMjAtMTItMDRUMTQ6MDg6MjgtMDY6MDAiLCJpc3N1ZXIiOiJkaWQ6a2V5Ono2TWtvVEhzZ05OcmJ5OEp6Q05RMWlSTHlXNVFRNlI4WHV1NkFBOGlnR3JNVlBVTSIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJEb21haW5MaW5rYWdlQ3JlZGVudGlhbCJdfX0.6ovgQ-T_rmYueviySqXhzMzgqJMAizOGUKAObQr2iikoRNsb8DHfna4rh1puwWqYwgT3QJVpzdO_xZARAYM9Dw"
  ]
}

Note the top-level linked_dids key. Particularly because of the possibility of did-configuration.json resolution becoming a part of the QR embedding strategy, I think a good first step would be to have this reference app be spec-compliant.

From there, the Health Cards spec could decide to dictate that only long-form DIDs be listed in did-configuration.json and could norm on using either JWS or JSON-LD proof objects.

Happy to help with this as well if you agree and it's not on the docket already.

This is a little bit challenging because 1) the configuration will not be long-lived because it the key material resets on every deployment... But that would be okay as long as anyone using the demo issuer takes this into account and 2) the current deployment allows for an end-to-end encryption mode where keys only ever exist in the browser and every browser has its own separate keys, so when using it in that mode it would not make sense to have a centrally hosted configuration file. But that could just be an exception / limitation.

(To replace or in addition to the "Open portal" menu link.)

• Proxy requests to https://c19.cards/examples to https://smarthealth.cards/examples
• Why? So we can add a application/smart-health-card MIME type for any .smart-health-cards returned this way, to allow for testing of MIME type handling (e.g., for Android app routing)

• Generate JWT public key as X and Y coordinates, from a non-compact secp256k1 key

• Generate a hash (input to signature algorithm) from bytes in a JWT header + payload

From chat discussions, the portal is being used by non-technical end-users as part of go-live procedures. It'd be good for us to have a full understanding of any tests that don't get surfaced in the portal, and then we can evaluate whether/how to close the gap.

One specific question that came up is whether CORS checks are performed

Can start with just a bullet list here if this makes sense to you @ljoy913

• List the name of the party with whom data will be shared
• List the types of credentials being requested
• Add a "do not approve" button

Some API calls right now just fail to return when an error occurs. Handlers should catch all.

E.g. when verifying a JWS, provide a way to specify the expected signer DID.

Looks like you recently updated the health card implementation guide to use ES256 instead of ES256K for JWT signing, but that hasn't gotten updated yet in this example implementation. We assumed that this code base reflected the most up to date decisions, that seems incorrect based off of the Git history.

Call sites to update:

• https://github.com/microsoft-healthcare-madison/health-wallet-demo/blob/61c91032e0d0f7ed3f797db4471dce7abb69ea6c/src/keys.ts#L115
• https://github.com/microsoft-healthcare-madison/health-wallet-demo/blob/bf9de724826d157689f0e0dbb3ab8926f6a32990/src/VerifierLogic.ts#L51

Happy to handle this change once you confirm this is desired.

cc @jmandel

Make sure current tests pass. issuanceDate shouldn't appear in the JWS (just nbf).

Maintain a cache of independent states, sharing keys as needed

Issue

Once you establish a set of VCs in the "Holder", you have the option to manually input a "verifier" URL to send them to by clicking the scanner button in the bottom-left.

I was attempting to navigate to this libs example verifier, when I came across the following issue.

Attempting to input a manual URL (and likely via QR code too), doesn't do anything except throw a console error.

Don't clone locally :)

@jmandel – 👋 – thanks for this awesome example app!

Context

I'm working with a group that's introducing health card functionality into our android application and we're using this codebase as a reference.

In particular, I'm trying to better understand ION DID resolution.

Understanding

My understanding so far:

• holders need to verify SIOP requests sent from issuers/verifiers to ensure authenticity of entity behind SIOP requests. The entry-point to this verification is verifyJWS

  • https://github.com/microsoft-healthcare-madison/health-wallet-demo/blob/bf9de724826d157689f0e0dbb3ab8926f6a32990/src/holder.ts#L193

• verifyJWS performs verification by calling the GET /api/did/:did endpoint with the full did (e.g. did:ion:1234#key-id)

  • https://github.com/microsoft-healthcare-madison/health-wallet-demo/blob/bf9de724826d157689f0e0dbb3ab8926f6a32990/src/dids.ts#L15
  • https://github.com/microsoft-healthcare-madison/health-wallet-demo/blob/bf9de724826d157689f0e0dbb3ab8926f6a32990/src/dids.ts#L38
  • https://github.com/microsoft-healthcare-madison/health-wallet-demo/blob/bf9de724826d157689f0e0dbb3ab8926f6a32990/src/server.ts#L462-L470

This leads us to resolveDid:

https://github.com/microsoft-healthcare-madison/health-wallet-demo/blob/bf9de724826d157689f0e0dbb3ab8926f6a32990/src/server.ts#L36-L52

It seems like this resolveDid implementation is incredibly similar to that implemented in the sidetree codebase itself, which I presume is your motivation in this implementation:

https://github.com/decentralized-identity/sidetree/blob/master/lib/core/versions/latest/RequestHandler.ts#L234-L244

Questions

It seems like this mock create operation doesn't actually read or write to the Bitcoin blockchain during resolution (based off of my reading of the sidetree source and playing around with this resolver), but just automatically returns a DID Document that is verified.

Am I thinking about this correctly? If so, what would a more "production" implementation of DID creation / resolution look like?

I appreciate these sorts of questions are not exactly related to health cards / VCs, but I imagine you might have some context/pointers here!

This isn't part of the official https://identity.foundation/sidetree/spec/ ; we should be using add-public-keys instead.