Hey @OR13 is there a reason that OKP / X25519 is not supported by this lib or is it just not in there yet? If it's the latter I can attempt a PR

JWT Verifiable Credential output in JWS-Test-Suite in some cases has claim "sub":{}:
https://github.com/decentralized-identity/JWS-Test-Suite/blob/5084057e83142f17a7656ca8f9d439eea97f08d3/implementations/transmute/credential-0--key-0-ed25519.vc-jwt.json (Edit: or a non-empty object for sub: decentralized-identity/JWS-Test-Suite#54 (comment))
This appears to be a conversion of an object credentialSubject from a verifiable credential (credentialSubject):
https://github.com/decentralized-identity/JWS-Test-Suite/blob/85e1b77be6197e21489526315fc3f5ec1e484dfe/data/credentials/credential-0.json
But the sub claim value is supposed to be a StringOrURI according to https://www.rfc-editor.org/rfc/rfc7519.html#section-4.1.2
In the case of credentialSubject without an id property, it might make sense to omit the sub claim.

https://github.com/OR13/lds-pgp2021

https://ns.did.ai/suites/pgp-2021/

Plugin users should be able to provide their own document loader.... "allowNetwork" style configuration will lead to more sadness than its worth.

Cannot find module '@transmute/json-web-signature' from 'node_modules/@transmute/vc.js/dist/vc.js.cjs.development.js'

Dependencies need to be fixed, can be reproduced by following readme instructions.

Seeing a lot of errors related to stringify and errors thrown by linked data libraries, for example:
https://github.com/decentralized-identity/JWS-Test-Suite/pull/29/files

We should ensure that all errors can be serialized by stringify safely.

account for faker data like:

{
  type: 'Organization',
  name: 'Ratke, Grant and Keebler',
  description: 'Enhanced needs-based knowledge user',
  logo: 'http://placeimg.com/640/480/business',
  website: 'miller.net'
}

https://github.com/transmute-industries/vc.js/tree/master/packages

vc js should only be about VCs, not linked data proofs and jsonld-signatures suites...

I am trying to create a credential and getting MISSING_PROPERTIES_IN_CONTEXT, I have verified json-ld and seems to be valid. Can you please suggest what I am missing?

My VC

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential"
  ],
  "issuer": {
    "id": "did:key:z6MkokrsVo8DbGDsnMAjnoHhJotMbDZiHfvxM4j65d8prXUr"
  },
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21"
  }
}

And the error

(node:41427) Warning: Accessing non-existent property 'abort' of module exports inside circular dependency
(Use `node --trace-warnings ...` to show where the warning was created)
Error: credential is not valid JSON-LD: {
  "type": "MISSING_PROPERTIES_IN_CONTEXT",
  "details": [
    "credentialSubject",
    "issuanceDate",
    "issuer"
  ]
}
    at /Users/Code/research/testvc/node_modules/@transmute/vc.js/src/checkCredential.ts:58:11
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

Thanks

On testing a MTR credential the library fails to expand the document on verification of the credential

{
      verified: false,
      error: VerificationError: Verification error(s).
          at /Users/adam/git/mute/verifiable-data/packages/linked-data-proof/src/verify.ts:33:22
          at processTicksAndRejections (internal/process/task_queues.js:93:5) {
        errors: [
          Error: The property "grade" in the input was not defined in the context.
              at strictExpansionMap (/Users/adam/git/mute/verifiable-data/packages/linked-data-proof/src/strictExpansionMap.ts:4:11)
              at _expandObject (/Users/adam/git/mute/verifiable-data/packages/ed25519-signature-2018/node_modules/jsonld/lib/expand.js:445:26)
              at Object.<anonymous>.api.expand (/Users/adam/git/mute/verifiable-data/packages/ed25519-signature-2018/node_modules/jsonld/lib/expand.js:248:9)
              at _expandObject (/Users/adam/git/mute/verifiable-data/packages/ed25519-signature-2018/node_modules/jsonld/lib/expand.js:795:35)
              at processTicksAndRejections (internal/process/task_queues.js:93:5)
              at Object.<anonymous>.api.expand (/Users/adam/git/mute/verifiable-data/packages/ed25519-signature-2018/node_modules/jsonld/lib/expand.js:248:3)
              at _expandObject (/Users/adam/git/mute/verifiable-data/packages/ed25519-signature-2018/node_modules/jsonld/lib/expand.js:795:25)
              at Object.<anonymous>.api.expand (/Users/adam/git/mute/verifiable-data/packages/ed25519-signature-2018/node_modules/jsonld/lib/expand.js:248:3)
              at Function.jsonld.expand (/Users/adam/git/mute/verifiable-data/packages/ed25519-signature-2018/node_modules/jsonld/lib/jsonld.js:325:18)
              at Function.jsonld.toRDF (/Users/adam/git/mute/verifiable-data/packages/ed25519-signature-2018/node_modules/jsonld/lib/jsonld.js:671:16)
        ]
      }
    }

"@transmute/credentials-context": "^0.7.0-unstable.6" should be a dependency and not a devDependency of @transmute/ed25519-signature-2018"

    Cannot find module '@transmute/credentials-context' from 'node_modules/@transmute/ed25519-signature-2018/dist/ed25519-signature-2018.cjs.development.js'

    Require stack:
      node_modules/@transmute/ed25519-signature-2018/dist/ed25519-signature-2018.cjs.development.js
      node_modules/@transmute/ed25519-signature-2018/dist/index.js
      packages/credential-w3c/src/ld-credential-module.ts
      packages/credential-w3c/src/index.ts
      __tests__/localAgent.test.ts

      at Resolver.resolveModule (node_modules/jest-resolve/build/resolver.js:311:11)
      at Object.<anonymous> (node_modules/@transmute/ed25519-signature-2018/dist/ed25519-signature-2018.cjs.development.js:12:12)

when only using "@transmute/ed25519-signature-2018": "^0.7.0-unstable.6", in package.json.

https://w3id.org/security/suites/ed25519-2018/v1
https://w3id.org/security/suites/ed25519-2020/v1
https://w3id.org/security/suites/x25519-2020/v1

for JWS and PGP

I tried to run the following code for the universal wallet vc plugin and got the error below. Does anyone know why it happened?
https://github.com/transmute-industries/verifiable-data/tree/main/packages/universal-wallet-vc-plugin/src/__tests__/JsonWebSignature2020
const vc = await plugin.issue({ credential: { ...credential, issuer: key.controller }, options: { suite, documentLoader } }); console.log(JSON.stringify(vc));

https://github.com/transmute-industries/verifiable-data/blob/main/packages/universal-wallet-vc-plugin/src/__tests__/JsonWebSignature2020/JsonWebSignature2020.static.test.ts

We are currently using it to sanity test web compatibility of modules.

We should keep doing that, but it would be nice to use the github and npm apis to try and pull together some usage metrics and transparency for the packages hosted here.

something like this

The following unsigned credential with an invalid issuanceDate is able to be signed.

    {
      '@context': [
        'https://www.w3.org/2018/credentials/v1',
        'https://www.w3.org/2018/credentials/examples/v1'
      ],
      id: 'http://example.edu/credentials/1872',
      type: [ 'VerifiableCredential', 'AlumniCredential' ],
      issuer: 'https://example.edu/issuers/565049',
      issuanceDate: {
        years: 1991,
        months: 7,
        date: 25,
        hours: 21,
        minutes: 33,
        seconds: 56,
        milliseconds: 789
      },
      credentialSubject: {
        id: 'https://example.edu/students/alice',
        alumniOf: 'Example University'
      }
    }

Will be signed in the ED25519-Signature suite.

    {
      '@context': [
        'https://www.w3.org/2018/credentials/v1',
        'https://www.w3.org/2018/credentials/examples/v1'
      ],
      id: 'http://example.edu/credentials/1872',
      type: [ 'VerifiableCredential', 'AlumniCredential' ],
      issuer: 'https://example.edu/issuers/565049',
      issuanceDate: {
        years: 1991,
        months: 7,
        date: 25,
        hours: 21,
        minutes: 33,
        seconds: 56,
        milliseconds: 789
      },
      credentialSubject: {
        id: 'https://example.edu/students/alice',
        alumniOf: 'Example University'
      },
      proof: {
        type: 'Ed25519Signature2018',
        created: '2021-10-15T12:33:56Z',
        verificationMethod: 'did:key:z6MktWjP95fMqCMrfNULcdszFeTVUCE1zcgz3Hv5bVAisHgk#z6MktWjP95fMqCMrfNULcdszFeTVUCE1zcgz3Hv5bVAisHgk',
        proofPurpose: 'assertionMethod',
        jws: 'eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..sSFwXkauRrVVmNmTJnRNK70WzU81gVz0mS9bJ6quIR5XyuIq2L29DS2zhJ8GKHjKkytLmR2MBVcfzRwBSDb0Cw'
      }
    }

The expected behavior is to throw an error when a date is found that doesn't match the schema.

https://github.com/miracl/core/tree/master/javascript

https://github.com/paulmillr/noble-bls12-381

We probably ought to support vanilla signatures in the basic key pair classes.

While we wait for BBS+ to harden.

Running the code with vc.js installed, it complains that jose is not found as a module.

So you might want to add it to the dependency tree and not as a dev dependency

#134

This is caused by trying to be too smart with lerna, the package does not exist on main... because we are trying to add it.

We can try to merge the PR and see if the error resolves, but this makes us nervous and sad.

https://www.npmjs.com/package/json-schema-to-ts

Hi @OR13,

I tried to create signing key and passed to sidetree element did method to generate the did e.g.

did:elem:ganache:EiD351yY0XqnbCJN2MaZSQJMgG-bqmgFMDRGKawfu6_mZA

I used the same key to create the credential with the result

{
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://w3id.org/security/suites/jws-2020/v1"
      ],
      "id": "http://example.edu/credentials/3732",
      "type": ["VerifiableCredential"],
      "issuer": {
        "id": "did:elem:ganache:EiD351yY0XqnbCJN2MaZSQJMgG-bqmgFMDRGKawfu6_mZA"
      },
      "issuanceDate": "2010-01-01T19:23:24Z",
      "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21" },
      "proof": {
        "type": "JsonWebSignature2020",
        "created": "2010-01-01T19:23:24Z",
        "verificationMethod": "did:key:z6MkokrsVo8DbGDsnMAjnoHhJotMbDZiHfvxM4j65d8prXUr#z6MkokrsVo8DbGDsnMAjnoHhJotMbDZiHfvxM4j65d8prXUr",
        "proofPurpose": "assertionMethod",
        "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..k_7t6h5IGSWFAqIlqru3zyZ0FDPQGo88p9jDeKC1yw8oxd7xj6B70tZNSaspWkMyWbXFmZ5yCO8dlZZ9_kKbAQ"
      }
    },

However, during the verification, there was an error: Credential issuer must match the verification method controller.

The documentLoader can resolve the did:elem:ganache:EiD351yY0XqnbCJN2MaZSQJMgG-bqmgFMDRGKawfu6_mZA and return the diddocument from the sidetree and it also can resolve the verificationMethod in the proof did:key:z6MkokrsVo8DbGDsnMAjnoHhJotMbDZiHfvxM4j65d8prXUr#z6MkokrsVo8DbGDsnMAjnoHhJotMbDZiHfvxM4j65d8prXUr.

https://github.com/btd/rollup-plugin-visualizer

Hi @OR13 , do you have an example of document loader for Microsoft ion or element that using the verifiable credential?

How to extract the issuer from the credential and verify the issuer did against the ledger e.g. if the issuer using did element before verify the credential itself.

@OR13 Should we include the DIDComm and DIDAuthentication in this project? What's the best method for authentication e.g. DidAuth or Did Siop?

the module works in node, but fails in the browser.

It looks like the browser does not convert the public key to a buffer, but the node module does...

from the node module:

from the browser:

steps to repro:

1. git clone [email protected]:transmute-industries/verifiable-data.git
2. cd verifiable-data
3. npm i

this error shows up. have tried 3x, same stuff.

npm ERR! command failed
npm ERR! command sh -c node-pre-gyp install --fallback-to-build=false
npm ERR! 404 status code downloading tarball https://github.com/mattrglobal/node-bbs-signatures/releases/download/0.11.0/node-v102-darwin-arm64.tar.gz
npm ERR! node-pre-gyp info it worked if it ends with ok
npm ERR! node-pre-gyp info using [email protected]
npm ERR! node-pre-gyp info using [email protected] | darwin | arm64
npm ERR! node-pre-gyp WARN Using request for node-pre-gyp https download 
npm ERR! node-pre-gyp info check checked for "/Users/gcohen/Development/verifiable-data/packages/bls12381-key-pair/node_modules/@mattrglobal/node-bbs-signatures/native/index.node" (not found)
npm ERR! node-pre-gyp http GET https://github.com/mattrglobal/node-bbs-signatures/releases/download/0.11.0/node-v102-darwin-arm64.tar.gz
npm ERR! node-pre-gyp http 404 https://github.com/mattrglobal/node-bbs-signatures/releases/download/0.11.0/node-v102-darwin-arm64.tar.gz
npm ERR! node-pre-gyp ERR! install error 
npm ERR! node-pre-gyp ERR! stack Error: 404 status code downloading tarball https://github.com/mattrglobal/node-bbs-signatures/releases/download/0.11.0/node-v102-darwin-arm64.tar.gz
npm ERR! node-pre-gyp ERR! stack     at Request.<anonymous> (/Users/gcohen/Development/verifiable-data/packages/bls12381-key-pair/node_modules/node-pre-gyp/lib/install.js:142:27)
npm ERR! node-pre-gyp ERR! stack     at Request.emit (node:events:532:35)
npm ERR! node-pre-gyp ERR! stack     at Request.onRequestResponse (/Users/gcohen/Development/verifiable-data/packages/bls12381-key-pair/node_modules/request/request.js:1059:10)
npm ERR! node-pre-gyp ERR! stack     at ClientRequest.emit (node:events:520:28)
npm ERR! node-pre-gyp ERR! stack     at HTTPParser.parserOnIncomingClient [as onIncoming] (node:_http_client:618:27)
npm ERR! node-pre-gyp ERR! stack     at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)
npm ERR! node-pre-gyp ERR! stack     at TLSSocket.socketOnData (node:_http_client:482:22)
npm ERR! node-pre-gyp ERR! stack     at TLSSocket.emit (node:events:520:28)
npm ERR! node-pre-gyp ERR! stack     at addChunk (node:internal/streams/readable:324:12)
npm ERR! node-pre-gyp ERR! stack     at readableAddChunk (node:internal/streams/readable:297:9)
npm ERR! node-pre-gyp ERR! System Darwin 21.3.0
npm ERR! node-pre-gyp ERR! command "/opt/homebrew/Cellar/node/17.4.0/bin/node" "/Users/gcohen/Development/verifiable-data/packages/bls12381-key-pair/node_modules/.bin/node-pre-gyp" "install" "--fallback-to-build=false"
npm ERR! node-pre-gyp ERR! cwd /Users/gcohen/Development/verifiable-data/packages/bls12381-key-pair/node_modules/@mattrglobal/node-bbs-signatures
npm ERR! node-pre-gyp ERR! node -v v17.4.0
npm ERR! node-pre-gyp ERR! node-pre-gyp -v v0.14.0
npm ERR! node-pre-gyp ERR! not ok

Trying to resolve https://github.com/mattrglobal/node-bbs-signatures/releases/download/0.11.0/node-v102-darwin-arm64.tar.gz directly also returns a 404

When I added the https://schema.org to the credential context. The following error occurred
"type": "jsonld.InvalidUrl",
"details": "Dereferencing a URL did not result in a valid JSON-LD object. Possible causes are an inaccessible URL perhaps due to a same-origin policy (ensure the server uses CORS if you are using client-side JavaScript), too many redirects, a non-JSON response, or more than one HTTP Link Header was provided for a remote context."

How to write the documentLoader to support https://schema.org for the following credential

{
 "credential": {
   "@context": [
     "https://www.w3.org/2018/credentials/v1",
      "https://schema.org"
   ],
   "type": [
     "VerifiableCredential",
     "CourseCredential"
   ],
   "issuer": {
     "id": "did:key:z6MkndAHigYrXNpape7jgaC7jHiWwxzB3chuKUGXJg2b5RSj",
   },
   "issuanceDate": "2021-07-26T01:05:05.152Z",
   "credentialSubject": {
     "id": "did:key:z6MkfxQU7dy8eKxyHpG267FV23agZQu9zmokd8BprepfHALi",
     "givenName": "Chris",
     "familyName": "Shin",
     "educationalCredentialAwarded": "Certificate Name"
   },
 }
}

currently we are stuck on node14 because of static fixture issues with wasm and bls12381.

I suggest we skip all bls12381 tests that break, and bump ci to use matrix and support node 16.

Abstract

We want a shared code base for implementing the vc-api , using libraries in this repo.

We want this code base to expose a docker and bare metal api that can be configured to expose cryptographic capabilities in an extensible manner, such that a standard build process can deploy a secured instance of the api that is unique per vendor (no key or auth-reuse, no bundling of keys for demo purposes).

Requirements

API Documentation

The documentation for the API SHALL be OAS3.0 and shall include security configuration associated with authentication and authorization.

API Features

The API SHALL support all defined http endpoints and schemas associated with the vc-api.

This includes stateful operations such as revocation and presentation exchange.

This implies database integrations and associated security considerations.

The API SHALL support did:key and did:web.

The API SHALL support well known did configuration.

The API SHALL support extensibility mechanisms for securely exposing key based capabilities, such as signing.

Testing

The API SHALL be testable in CI using github actions.

Conformance tests shall cover all exposed endpoints and all supported did methods.

The API SHALL cover all "credentials of interests" as defined in the traceability use cases and requirements section here:

https://w3c-ccg.github.io/traceability-vocab/#use-cases-and-requirements

The API SHALL expose digital bazaar libraries for testing in CI as part of conformance testing, using a facade pattern. This is to ensure that all test vectors associated with API conformance have been evaluated by at least 2 independent implementations.

Existing implementations:

• https://github.com/transmute-industries/vc.transmute.world ( docker on GCP )
• https://github.com/transmute-industries/api.did.actor ( vercel / cloud functions )

https://github.com/w3c-ccg/vc-status-list-2021/pull/15#discussion_r792015187

Need tests, and to confirm, idempotence, deterministic compression / expansion.

The lib says that toISOString of new Date is wrong format, and It is because of the . fractions on the seconds that toISOString produces.

But according to the spec: https://www.w3.org/TR/xmlschema11-2/#nt-seFrag, that is a valid format?

And is not this the time format the verifiable credentials following?

It only seems to accepts this format "YYYY-MM-DDTHH:mm:ss[Z]"

Where the [Z] is just a string. This test running does not accepte offsetData such as +0100 which is pretty critical

Hi @OR13 ,

I noticed that there are 2 standards below. Which one is using on this project?
https://identity.foundation/presentation-exchange/ and https://identity.foundation/waci-presentation-exchange/

Do you have a complete example how to create the presentation definition as I can only see the example how to create the presentation credential?

Thanks
Thomas

https://github.com/transmute-industries/did-key.js/tree/master/packages/did-key-cipher

These kinds of linked data crypto libraries belong here, not in did key repo.

Digital Bazaar changed their document loader from a resolver to a derferencers
This means to remain interopable, we need to change our document loaders to also implement this change
so that for the same input, we return the same document fragment

In terms of disambiguation, the difference between a resolver and a derferencer.
A resolver will load a document from a url, and return the entire document
A derferencer will load a specific fragment after loading the document from a url

In terms of dids, the use-case is that a resolver returns an entire did document, and
a derferencer will return a specific key inside the did document.

This is a container issue on this repository to track and make sure that we update our document loaders
in this repository.

When generating a key it is default type JSONWebKey2020, meaning that the type cannot declare what type this key should be converted to?

Either one have to use the did:key identifier in itself? Or stor on the side the intended type of the key?

Because a JWK for BLSG2 key cannot be created using from of a ED key right?

Just wanting to make sure I understand the logic 100% here

We need to implement the interfaces for minimal cipher / linked data proof suite keys...

sign, verify, derive, toKeyPair, toJsonWebKey, etc...

 async generate() {
    const keyPtr = this.instance._dilithiumGenerate();
    const keyPair = this.getCString(keyPtr, KEYPAIR_BYTES_B64 * 2, true);
    return JSON.parse(keyPair);
  }

it would be nice to be able to pass a secureRandom function that we could link up to mnemonics or other dangerous sources of low entropy... for testing purposes.

Due to jest / esm module issues, we are having trouble testing things, and its leading to less tests.

We need to fix this issue by generating some test vectors from their libraries, and confirming support for them in ours.

We should treat digital bazaar libraries as the source of truth.

We should create a package in this repo which imports their libraries, and produces test vectors as a node module for the following cases:

• Ed25519Signature2018
• linked data proofs (jsonld-signatures)
• vc.js - verifiable credentials
• revocation list verifiable credentials

Then we should add to this package, suites we have written which they don't currently maintain:

• JsonWebSignature2020
• BbsBls.... (be careful with blank nodes and derive)

Then we should add to this package test vectors of interest, starting small and ending complex:

• simple single context credentials
• permanent resident card vc
• vaccination vc
• CMTR vc
• verifiable business card vc

At the end of this process, we should have a node module called @transmute/vc-data-model-test-vectors, it should export json for all inputs and outputs, it should have only dev dependencies, it should have a document loader that hard codes all contexts, revocation lists, dids and any URI that might normally require network.

Refactor key pair classes:

• secp256k1
• ed25519
• x25519
• bls12381
• p256
• p384
• p521

Refactor did-key-common:

• generalize resolution for content types
• ensure ld-key-pair-class conformance

Refactor did-key.js :

• include all key pair classes
• add support for dereferencing

Hi,

I am implementing some did verification process in a library that runs both in the browser and on node. One of the dependencies (I believe it would be @transmute/did-key-secp256k1) relies on this library.

When I am bundling with rollup, I get the following error:

[!] Error: 'staticImplements' is not exported by node_modules/@transmute/ld-key-pair/dist/index.js, imported by node_modules/@transmute/secp256k1-key-pair/dist/secp256k1-key-pair.esm.js
https://rollupjs.org/guide/en/#error-name-is-not-exported-by-module
node_modules/@transmute/secp256k1-key-pair/dist/secp256k1-key-pair.esm.js (3:9)
1: import { __decorate } from 'tslib';
2: import secp256k1 from 'secp256k1';
3: import { staticImplements } from '@transmute/ld-key-pair';
                  ^

indeed the entry file looks like this:

if (process.env.NODE_ENV === 'production') {
  module.exports = require('./ld-key-pair.cjs.production.min.js')
} else {
  module.exports = require('./ld-key-pair.cjs.development.js')
}

And it does not seem rollup is capable of interpreting this dynamic import? Or do you know of a way?

Thanks

See proposal here: transmute-industries/did-key.js#87 (comment)

@OR13 Do you have any test case or instruction for the passwordless authentication using VP exchange?

When using the non default options for verifying a mill test report verifiable credential, specifically compactProof, results in a failure to verify.
compactProof: true with expansionMap: undefined or true results in the error The property "grade" in the input was not defined in the context.
compactProof: true with expansionMap: false results in an invalid signature. All other expansionMap and compactProof result in successful verification.

1. we don't convert to datetime xml format e.g. 2010-10-19T14:47:38-05:00 -> 2010-10-19T19:47:38Z, 2010-10-19T14:47:38.123Z -> 2010-10-19T14:47:38Z, currently it passes the incorrectly formatted date as is
2. we don't error on nonsense strings e.g. foobar -> error, currently it passes the nonsense string as is
3. we don't error on empty strings e.g. "" -> error, currently it gets set to current time
4. we don't pass current time for null e.g. null -> current time, currently it passes epoch time.

I have a VC that is trying to stick to JSON LD structure, and should really fail accroding to: https://github.com/transmute-industries/verifiable-data/blob/main/packages/jsonld-schema/src/check/check.ts#L68

But this is not failing with the current library any idea why?
Im trying to understand how the context and the type stick together and help my code and me understand what to do.

{
  '@context': [
    'https://www.w3.org/2018/credentials/v1',
    'https://w3id.org/traceability/v1'
  ],
  issuer: 'did:key:z6MkqjFswaqkXJ7SRUZ8G9m1RtcjpXps1RZRKo4mFYZy5bWx',
  type: [ 'VerifiableCredential', 'ContactPoint' ],
  name: 'Verified phone number',
  description: 'This is a credential of phone number attribute that has been verified through sending an sms to the owner',
  issuanceDate: '2021-12-06T11:38:21Z',
  credentialSubject: {
    id: 'did:key:z6MkfwmZep5ZvkHfeXszxhxEuvkmGFRc8H9Nv9ZaQG4vhFzZ',
    identifier: '7870dab0-f8f5-11eb-b356-657b2e987fed',
    hhohoo: '+46456812311'
  }
}

https://github.com/transmute-industries/verifiable-data/blob/main/packages/universal-wallet-vc-plugin/src/__tests__/BbsBlsSignatureProof2020/BbsBlsSignatureProof2020.static.test.ts#L85

Recent changes appear to have encoded the JWT signature as a JWT with detached payload...

The JOSE package on npm should be used to create a series of JWT test vectors and their interop with our libraries here should be confirmed.