PROPOSAL: Restrict conformance and interop test suites to did:key only.

[OR13]

Proposal: The VC HTTP API Test Suite SHALL ONLY support did:key for both interop and conformance test suites. The spec MUST note that this is not an endorsement of did:key as the only solution, it is a decision to make production interoperability possible, similar to the requirement that all OAuth providers support P256.

[mprorock]

Big plus one from mesur.io

[brianorwhatever]

+1 here as well. This will also create a baseline number of tests so that implementers can compare apples to apples. did:key is trivial to implement and makes a lot of sense to use for conformance.

[peacekeeper]

I thought we said we want this constraint for conformance tests, but not for interop tests?

[OR13]

@peacekeeper IMO, the interop testing in this test suite is about VCs not DIDs... I think if we can focus this test suite on did:key only and VCs, we can do a better job of interop testing DID resolution here: https://github.com/w3c-ccg/did-resolution/issues/64

[OR13]

certainly we need did method interop testing somewhere, for methods other than just did:key, but I think the did resolution tests would be a better place to do it.

[msporny]

Certainly we need did method interop testing somewhere, for methods other than just did:key,

I'll note that we'd need a did:key test suite as well :)

My expectation is that we're not all as interoperable as we think we are there. For example, I expect gaps in secp256r1 (P-256 vs P-384), secp256k1, and BBS+.

[peacekeeper]

I think if we can focus this test suite on did:key only and VCs

I'm fine with constraining the entire VC HTTP API test suite to did:key, but right now the SVIP Testing Strategy Google doc (which I think motivated this issue here) seems to suggest that within the VC HTTP API test suite, there would be 1. did:key only for conformance tests, and 2. multiple DID methods for interop tests.

Just pointing out a discrepancy between the Google doc and this issue here.

[msporny]

I suggest that we further constrain to ed25519 did:key -- if we don't do that, it'll create more variation on something we don't want to have variation on.

[mprorock]

I suggest that we further constrain to ed25519 did:key

Highly supported from our side - keeping the conformance testing clean, simple, and as offline as possible is highly desirable

[brianorwhatever]

While I agree with this in principle it would be a shame not to include bbs+ given the attention it is attracting. There would also be no way to test the derive credential endpoint without it..

On Wed, Jun 16, 2021 at 8:24 AM Mike Prorock @.***> wrote:

I suggest that we further constrain to ed25519 did:key

Highly supported from our side - keeping the conformance testing clean, simple, and as offline as possible is highly desirable

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/vc-http-api/issues/184#issuecomment-862474121, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWK6FHP6MVFVD377CQPZWTTTC63LANCNFSM443C5LDA .

[msporny]

While I agree with this in principle it would be a shame not to include bbs+ given the attention it is attracting. There would also be no way to test the derive credential endpoint without it..

Sure, perhaps the derive credential endpoint does did:key BBS+ -- but everything else is ed25519. That is, if there is any way to do ed25519, we do that... and for endpoints that need something else, we take them on a case-by-case basis.

[OR13]

We can't restrict did:key to ed25519 and meet the requirements for P-384 / BBS+...

See: https://github.com/w3c-ccg/vc-http-api/issues/130

[OR13]

There are currently no other paring friendly curves (BLS12381) that support JSON-LD BBS+ style deriveCredential... but in the future there might be.

[msporny]

We can't restrict did:key to ed25519 and meet the requirements for P-384 / BBS+...

To channel your requirement for the test suite -- why are we testing key types in this API? We should be testing the API, not crypto agility, no?

[OR13]

@msporny we are testing vc.proof.type in the API... IMO, having 3 values for that is better than 2.

For ensuring that linked data proofs are implemented properly.

The fact that multiple did:key's are required is a dependency of proving that multiple proof types are supported.

Since multiple curve's are required, to show that multiple proof types can be supported.

We might further restrict to did:key in application/did+json, which uses JWKs instead of publicKeyMultibase...

unless we are ok using publicKeyMultibase even though it is less mature than GNAP...

https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/

https://datatracker.ietf.org/doc/draft-multiformats-multibase/

I can't ping Justin or Adrian in GitHub, or I would.

[mprorock]

@msporny we are testing vc.proof.type in the API... IMO, having 3 values for that is better than 2.

Think we need to be careful to ensure that basic conformance and interop are not necessarily conflated, and from a base testing standpoint identify which ares, such as deriveCredential where something other than ed25519 may be required. I think @OR13 has identified another related to vc.proof.type testing. any other specific areas we are missing that may require another crypto type?

[OR13]

Backing up to answer @msporny question directly:

We should be testing the API, not crypto agility, no?

How can we test the API without testing cryptographic agility?

I would assert thats not really possible for such an API, unless you think an API that only supports 1 credential format is a VC api... which sounds very similar to ZKP-CL.

I think we will encounter a problem on this front... folks will want to use this API to show that their proof.type is interoperable... thats for "interoperability tests".

Separate from that is "conformance tests"... you cannot pass them today and only support Ed25519.

We would need to drop support for BBS+.

We could safely drop P-384 from conformance tests and still have full conformance coverage with 2 key types.

[selfissued]

We want to test JWK keys because they use a general-purpose, widely deployed industry standard that's used by the DID spec. If people also want to test Multibase, we could but it's not a standard and has more limited capabilities. Note that the Multibase reference in the DID spec is to an individual Internet Draft that's not in any working group - and therefore that has no standing as a standard.

[msporny]

@OR wrote:

How can we test the API without testing cryptographic agility?

Please read https://github.com/w3c-ccg/vc-http-api/issues/184#issuecomment-862479957 carefully.

I've already conceded that we do BBS+ and ed25519... but that's it. Let's keep this simple.

For ensuring that linked data proofs are implemented properly.

Isn't that the job of the LD test suite? Your whole argument was that conformance and interop test suites shouldn't be testing DID Methods. Now the argument seems to be -- but they should be testing LD cryptosuites? The argument feels inconsistent and like it's opening up scope.

Why can't we just do BBS+ and ed25519 and be done with it? Everything else, including testing cryptographic agility, is for the LD Signatures test suite.

[OR13]

Why can't we just do BBS+ and ed25519 and be done with it?

we can... but should they be publicKeyMultibase or publicKeyJwk

or does that distinction not matter? probably it does not matter if your suite supports both (as ours does for Ed25519).

However, I have observed that some vendors cannot verify credentials issued from JWKs, especially for BBS+.

In our tests for did:key today, with request application/did+json for every did key, except for bls12381, where we request application/did+ld+json... because Mattr's suite does not parse JWK (or did not, last time i checked).

this kind of thing is 100% out of scope for this work item, but its related to understanding the questions raised on the last call regarding the cost of a "full test harness" vs "just use did:key".

[msporny]

should they be publicKeyMultibase or publicKeyJwk

lol -- I look forward to re-igniting the long dead key format debate from the DID WG in the VC HTTP API. I see that @selfissued is already here with popcorn. :P

[OR13]

@msporny I know... this is what i meant by "the path towards mocking is more expensive than you might think" : )

[TallTed]

@OR13 --

I can't ping Justin or Adrian in GitHub, or I would.

Assuming I know which Justin or Adrian you mean, and that you really (and still) want to, and hoping that you have some specific thoughts about what you could ask them to contribute to this discussion, they're easy to ping, as they both have easily discovered github handles...

[mavarley]

Given the test suite has moved to https://github.com/w3c-ccg/vc-api-test-suite recommend closing this issue.

[msporny]

recommend closing this issue.

+1

I'll also note that we have other test suites that we're working on that do not require an interop profile for all test suites... for example, the "soon to be moved to the CCG" VC API modular test suites don't test the actual signature, they just check to make sure the API exists and returns something that's well-formed:

• https://digitalbazaar.github.io/vc-api-verifier-test-suite/
• https://digitalbazaar.github.io/vc-api-issuer-test-suite/

... while the Ed25519 test suite uses the same API endpoints, but then checks the actual digital signature format:

• https://digitalbazaar.github.io/di-ed25519-test-suite/

This approach allows us to test the shape of the VC API without requiring any particular cryptosuite... and then we also have cryptosuite test suites that do require very specific output (proper digital signatures).

All that said, I do agree that all tests suites that are not testing very specific aspects of DIDs use did:key.

[msporny]

Looks like most, if not all, of the VC API test suites now use some variation of did:key, closing.