Sample code or library to create DID Configuration (VP) from VC?

[sondreb]

The sample provided on the foundation website, is there any sample code or library that can be used to derive this "presentation" from the VC JWT that is included?

https://identity.foundation/.well-known/did-configuration.json

Do I have to manually map this in my own code, or does there exists something I could use?

I'm basically doing a software where when you set it up, you supply your DID and private key, and it will generate a signed "did-configuration.json" that will be provided by others who add your public server to their list of "vaults".

When users add a new server based on their domain name, the did-configuration.json will be verified, the software will do an DID resolving and get metadata for the server, like "name" and "description".

So in essence, convert an DID JWT VC to a type of DomainLinkageCredential to be included in the did-configuration.json.

[csuwildcat]

I believe @OR13 may have something for this. I'll look around myself, and create one if needed.

[OR13]

Assuming you use the universal wallet interop spec, or similar...

const getDidConfiguration = async (wallet) => {
  const dids = Array.from(
    new Set([
      ...wallet.contents.map((k) => {
        return k.controller;
      }),
    ])
  ).filter((d) => {
    return !d.startsWith("did:key:zAC");
  });

  const vcs = await Promise.all(
    dids.map(async (did) => {
      const kp = wallet.contents.find((k) => {
        return k.controller === did && k.publicKeyJwk.crv !== "BLS12381_G1";
      });

      const suite = await getSuite(kp);

      const credential = {
        "@context": [
          "https://www.w3.org/2018/credentials/v1",
          "https://identity.foundation/.well-known/contexts/did-configuration-v0.2.jsonld",
        ],
        issuer: kp.controller,
        issuanceDate: moment().toISOString(),
        expirationDate: moment().add(1, "year").toISOString(),
        type: ["VerifiableCredential", "DomainLinkageCredential"],
        credentialSubject: {
          id: kp.controller,
          origin: "https://example.com",
        },
      };

      if (kp.publicKeyJwk.crv === "BLS12381_G2") {
        credential["@context"].push("https://w3id.org/security/bbs/v1");
      }

      return vcjs.ld.issue({
        credential,
        suite,
        documentLoader,
      });
    })
  );
  return {
    "@context":
      "https://identity.foundation/.well-known/contexts/did-configuration-v0.2.jsonld",
    linked_dids: [...vcs],
  };
};

https://github.com/transmute-industries/verifiable-data/blob/main/packages/universal-wallet-fastify-plugin/src/getSuiteForKey.ts

https://github.com/transmute-industries/vc.js

We've not finished the plugin yet, but this is essentially how to do it.

( We won't be supporting the JWT format ).

[sondreb]

Thanks for the comments, so if I understand this correctly, the linked_dids is list of VCs. In the example on identity.foundation website, the JWT is included in combination with the VC as JSON.

What I don't understand fully is that the "origin" in the JSON returned contains "http://" prefix, while the payload of the JWT does not contain the URL prefix. Is this intentional or by mistake? In my code I'm basically generating the VC encoded as JWT, then decoding that to get the payload.vc which I'm putting into the readable JSON part of my generated did-configuration.json.

I have implemented most of this logic now, the only thing I'm missing is the "proof" on the VC. Any hint on direction to look to find a way to add proof to my VCs would be appreciated. I'm currently relying on did-jwt, did-jwt-vc, @transmute/did-key-secp256k1 and @transmute/did-key-secp256k1/dist/keyUtils. There is a "Proof" interface in did-jwt-vc, but not able to see how to get it included with the VC.

The result looks like this, and to verify this with my own resolver, I'm grabbing the JWT and verifying that, while ignoring the JSON parts of this document. Does that sound about right?

https://www.blockcore.net/.well-known/did-configuration.json

{
    "@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"
            ],
            "type": [
                "VerifiableCredential",
                "DomainLinkageCredential"
            ],
            "credentialSubject": {
                "id": "did:is:PMW1Ks7h4brpN8FdDVLwhPDKJ7LdA7mVdd",
                "origin": "blockcore.net"
            },
            "expirationDate": "2121-04-04T16:33:38.205Z",
            "issuanceDate": "2021-04-04T16:33:38.205Z",
            "issuer": "did:is:PMW1Ks7h4brpN8FdDVLwhPDKJ7LdA7mVdd"
        },
        "eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NksifQ.eyJleHAiOjQ3NzMyMjc2MTgsInZjIjp7IkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL3YxIiwiaHR0cHM6Ly9pZGVudGl0eS5mb3VuZGF0aW9uLy53ZWxsLWtub3duL2RpZC1jb25maWd1cmF0aW9uL3YxIl0sInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJEb21haW5MaW5rYWdlQ3JlZGVudGlhbCJdLCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6ImRpZDppczpQTVcxS3M3aDRicnBOOEZkRFZMd2hQREtKN0xkQTdtVmRkIiwib3JpZ2luIjoiYmxvY2tjb3JlLm5ldCJ9LCJleHBpcmF0aW9uRGF0ZSI6IjIxMjEtMDQtMDRUMTY6MzM6MzguMjA1WiIsImlzc3VhbmNlRGF0ZSI6IjIwMjEtMDQtMDRUMTY6MzM6MzguMjA1WiIsImlzc3VlciI6ImRpZDppczpQTVcxS3M3aDRicnBOOEZkRFZMd2hQREtKN0xkQTdtVmRkIn0sImlzcyI6ImRpZDppczpQTVcxS3M3aDRicnBOOEZkRFZMd2hQREtKN0xkQTdtVmRkIiwibmJmIjoxNjE3NTU0MDE4LCJzdWIiOiJkaWQ6aXM6UE1XMUtzN2g0YnJwTjhGZERWTHdoUERLSjdMZEE3bVZkZCJ9.AtMR7AFiEawqhqm4nhHLkOiTcxP-tkwG2Bd2ZMDvLmDZt5ZjTBa0VNv4bYRGHdCqKhqoRfu9Stb_PX0RRtVLBQ"
    ]
}

[csuwildcat]

@sondreb the https: scheme is part of the origin, and https: scheme paired with the authority portion of a domain address form a Secure Context: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts. The spec requires the linkage to be an https: prefixed-origin to ensure the assertions have the protections of a Secure Context.

[sondreb]

Thanks, I also noticed that the specification gives an example for "Compact JWT Domain Linkage Credential", this requires an header with "kid". The example in the documentation contains "kid", but the JWT provided by here does not have "kid" in the JWT header. It's not compliant with the latest specification, right?

I will modify my code to ensure that the "kid" is provided in the JWT header. I also see that I could also drop doing the JSON formatted key, but I'll leave it in there for human readability.

Unfortunately the createVerifiableCredentialJwt method does not support overriding header values, I'll add an issue on that git repo: decentralized-identity/did-jwt-vc#69

Already updated my server to include full URL as origin. It means that the identity.foundation configuration is wrong, right? The JWT encoded version does not include https prefix, while the JSON encoded does.

[csuwildcat]

@sondreb that example may be wrong, I'll have to take a look

[csuwildcat]

@sondreb the verbose example JSON object in the spec is errantly missing the https: scheme in front of the origin domain - would you care to submit a PR to correct it?

[sondreb]

I would love to do a PR, but I don't have the private key for did:key:z6MkoTHsgNNrby8JzCNQ1iRLyW5QQ6R8Xuu6AA8igGrMVPUM.

[csuwildcat]

@sondreb I thought it was just an errant example paste error, vs the actual signed example JWT. If that's the case, I believe @OR13 has what's needed to update it.

[jceb]

@Oran-Dan