Testing deriving credential without credential subject id

[brianorwhatever]

This test suite shows that it is currently not possible to derive a credential with a credentialSubject using a blank node identifier. The frame drops the credentialSubject entirely in this case.. This should be possible with a JSON-LD frame as shown in this playground.

Related issues:

• bundle with src? mattrglobal/jsonld-signatures-bbs#121
• Removing credentialSubject.id causes null credentialSubject mattrglobal/jsonld-signatures-bbs#128

FYI I added the DID context so that I could use the alsoKnownAs attribute for the credential subject

[OR13]

Interesting, you can pull only that term if you don't need the whole did context:

{
  "@context": [
    "https://www.w3.org/2018/credentials/examples/v1",
    "https://w3id.org/security/suites/bls12381-2020/v1",
    {
      "alsoKnownAs": "https://www.w3.org/ns/activitystreams#alsoKnownAs"
    }
  ]
}

[OR13]

Also old, but possibly related: mattrglobal/jsonld-signatures-bbs#91

[OR13]

This unit test should be modified to test just the LD Suite by itself...

https://github.com/transmute-industries/verifiable-data/tree/main/packages/linked-data-proof/src/__tests__/BbsBlsSignatureProof2020.transmute

We should amend this test to directly cover the examples from the spec:

noted here: https://w3c-ccg.github.io/ldp-bbs2020/#example-12

[OR13]

const NodeEnvironment = require("jest-environment-node");

// const WebEnvironment = require("jest-environment-jsdom");

const { TextEncoder, TextDecoder } = require("util");

class MyEnvironment extends NodeEnvironment {
  constructor(config) {
    super(
      Object.assign({}, config, {
        globals: Object.assign({}, config.globals, {
          Uint32Array: Uint32Array,
          Uint8Array: Uint8Array,
          ArrayBuffer: ArrayBuffer,
          TextEncoder: TextEncoder,
          TextDecoder: TextDecoder,
        }),
      })
    );
  }

  async setup() {}

  async teardown() {}
}

module.exports = MyEnvironment;

Jest mauls things in ways that bust wasm.... custm jest env is needed.

[OR13]

@brianorwhatever I was able to figure this out... I suspect its caused by some odd behavior with the frames...

See the examples, here:

#77

Specifically, this https://github.com/transmute-industries/verifiable-data/pull/77/files#diff-bc816a7381e5e69a57ca7889df4dc7ce2a41b470a6508e0201b59b326e2000f1R1

[OR13]

I was surprised this frame worked:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/security/suites/bls12381-2020/v1"
  ],
  "type": ["VerifiableCredential"],
  "credentialSubject": {
    "alsoKnownAs": { "id": {} }
  }
}

and this one did not...

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/security/suites/bls12381-2020/v1",
     {
       "alsoKnownAs": "https://www.w3.org/ns/activitystreams#alsoKnownAs"
     }
  ],
  "type": ["VerifiableCredential"],
  "credentialSubject": {
    "alsoKnownAs": { "id": {} }
  }
}

[OR13]

@brianorwhatever can you see if my latest PR addresses what you needed, and close this one or use that PR to modify this one as you need.

[brianorwhatever]

Yeah it looks like your new bbs suite tests are quite good. I like the cross testing with mattr lib as well. That's probably a better way to test the derived credential then against another json doc. I had begun work on creating a test case more similar to the examples in waci-pex but that repo would obviously be better for that work so we can do that there. I had been wondering if the subject not having a type attribute was effecting this but I don't think that's the case.

I'm interested in why the

"credentialSubject": {
    "alsoKnownAs": { "id": {} }
  }

form of the frame doesn't have the "@explicit": true and how I'll distinguish whether that is required. I'm also wondering what to do with a credentialSubject that does have a type property. Should it be included in the frame at all?

Closing this as you have solved the issue with this new suite.. Great work!