Add links from stalled prs

[OR13]

• move pgp to other deliverables section per feedback on Add a possible reference for pgp as a cryptosuite #50
• move multikey to other deliverables section per feedback on to allow for multibase support in the VCDI spec #51
• add json web signature test suite per v2 Test Suite #64

---

Preview | Diff

[msporny]

I only object to one line in the PR (that sends a mixed message). Remove it and I will approve.

[msporny]

This is the only line I would object to. We put publicKeyMultibase and Multikey in DID Core with the explicit goal to finish standardizing it in the VC 2.0 WG. This is a normative deliverable, to be defined in Data Integrity, and must remain as such.

[OR13]

This is a normative deliverable, to be defined in Data Integrity, and must remain as such.

I didn't touch that part of the charter, which already covers Ed25519 2020 and with your PR (#63) will add Secp384r1 2022.

Until the normatively deliverables cover other popular key formats (like P-256 / ES256) which is mandatory here: https://www.iana.org/assignments/jose/jose.xhtml

I think its smart for us to keep the door open to working on them non normatively.

[OR13]

@msporny either update your PR (#63) to cover P-256 (and others), or accept this PR to allow us to define them non normatively... we can't skip over mandatory to implement key and signature formats and expect to have the charter approved.

Another alternative would be to move the LD specific key and signature representations that are not based on JWS to the section in this PR.

I don't consider the current attempts at defining and omitting specific keys and signatures in this WG to be a path to success.

It's going to lead to formal objections for not addressing the topic consistently.

Either publicKeyMultibase is a viable alternative to publicKeyJwk, or our charter should close the door on it, and allow us all to focus on other components of this specification.

[msporny]

Either publicKeyMultibase is a viable alternative to publicKeyJwk, or our charter should close the door on it, and allow us all to focus on other components of this specification.

Can you please explain how what is proposed in this spec (normative deliverable of WG) doesn't make publicKeyMultibase a viable alternative to publicKeyJwk?

• https://w3c-ccg.github.io/data-integrity-spec/#multikey
• https://w3c-ccg.github.io/data-integrity-spec/#verification-material (see ISSUE 8)

The goal there is to define all possible key types in the multicodec table, which include (IIRC) all key types that are possible to be expressed in publicKeyJwk. You asked me to write spec text to enable that, I did that, and now you are still suggesting that that didn't happen. Have you read the spec text? What am I missing here?

Please state, concretely, why you believe the Multikey that you want is not supported via a normative work item that is currently listed in the charter?

[OR13]

@msporny your PR #63

is titled:

[DO NOT MERGE YET] Add ECDSA secpr1 cryptosuite to VCWG input documents.

And it points to:

https://digitalbazaar.github.io/di-ecdsa-secpr1-2019/

Which in turn looks like this:

https://digitalbazaar.github.io/di-ecdsa-secpr1-2019/#ecdsasecp256r1signature2019

I suppose we might consider this "close enough"... but its not defining:

• Ed25519
• Secp256k1
• Bls12381
• RSA

I guess if we add up all the CCG specs for key types and signatures, we do indeed have a working solution (except for RSA and P-521).

My point was that its pretty painful to have to review:

• https://digitalbazaar.github.io/di-ecdsa-secpr1-2019/ ( Secp256r1 + Secp384r1 (and not P-521) )
• https://w3c-ccg.github.io/ldp-bbs2020/ (Bls12381)
• https://w3c-ccg.github.io/lds-ed25519-2020/ (Ed25519)
• https://w3c-ccg.github.io/lds-ecdsa-secp256k1-2019/ (Secp256k1)
• no spec for RSA

If you are saying that this is just a function of where the input documents are today / how they were created, and that indeed our intention truly is to solve this key type and signature type for all entries in:

https://github.com/multiformats/multicodec/blob/master/table.csv#L90

We are aligned, but this feels significantly less concrete than a single document stating this clearly.

We have such a document, here: https://w3c-ccg.github.io/data-integrity-spec/#multikey

Perhaps we don't need all these suites in the "normatively defined" section if we have the link above? (which is already in the normative section?)

This PR (#73) makes it clear that we do intend to address these concerns at least non normatively for existing crypto that we are using today.

I will be happy to remove multikey from the non normative section, or approve your PR if it removes it from this section in the future.

If you require me to remove a non normative reference to the key format we use to address these issues currently, which is already conformant with https://w3c-ccg.github.io/data-integrity-spec/#multikey modulo choices for names, I can do that.

[OR13]

@msporny I have accepted your change suggestion, we can tackle the rest of the commentary on this thread via this issue:

#54

[selfissued]

Looking at the diffs, it doesn't appear that this adds a reference to the test suite. I'd prefer that we did.

[brentzundel]

@OR13 what is the status of this PR? Does it still reflect changes you feel are needed, or would it be best to see what happens with PR #77 before merging?

Also, I share Mike's question about a reference to the test suite and agree that is should be included.

[msporny]

We should collapse all items above to "Test Suites for WG-defined crypographic container formats and suites."

[OR13]

closing due to instability in the section, I will take another stab when it settles.