-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PROPOSAL: Restrict conformance and interop test suites to did:key only. #184
Comments
Big plus one from mesur.io |
+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. |
I thought we said we want this constraint for conformance tests, but not for interop tests? |
@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: w3c/did-resolution#64 |
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. |
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+. |
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. |
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. |
Highly supported from our side - keeping the conformance testing clean, simple, and as offline as possible is highly desirable |
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
<#184 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABWK6FHP6MVFVD377CQPZWTTTC63LANCNFSM443C5LDA>
.
|
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. |
We can't restrict did:key to ed25519 and meet the requirements for P-384 / BBS+... See: #130 |
There are currently no other paring friendly curves (BLS12381) that support JSON-LD BBS+ style |
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? |
@msporny we are testing 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 unless we are ok using 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. |
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 |
Backing up to answer @msporny question directly:
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 Separate from that is "conformance tests"... you cannot pass them today and only support 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. |
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. |
@or wrote:
Please read #184 (comment) carefully. I've already conceded that we do BBS+ and ed25519... but that's it. Let's keep this simple.
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. |
we can... but should they be 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 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". |
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 |
@msporny I know... this is what i meant by "the path towards mocking is more expensive than you might think" : ) |
@OR13 --
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... |
Given the test suite has moved to https://github.com/w3c-ccg/vc-api-test-suite 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:
... while the Ed25519 test suite uses the same API endpoints, but then checks the actual digital signature format: 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. |
Looks like most, if not all, of the VC API test suites now use some variation of did:key, closing. |
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.
The text was updated successfully, but these errors were encountered: