Add ECDSA secpr1 cryptosuite to VCWG input documents.

[msporny]

This PR adds the ECDSA secpr1 cryptosuite to the set of VCWG input documents. The work item is currently being processed for adoption by the CCG:

w3c-ccg/community#228

The PR is meant to be a placeholder until its adoption in CCG (and then the URLs to the spec will be updated).

---

Preview | Diff

[peacekeeper]

Yes this is a useful addition.

[OR13]

AFAIK the charter can in fact refer to work items anywhere on the internet... not just in the W3C CCG.

[msporny]

I expect W3C AC Members to raise IPR concerns if they see that a draft is being pulled in (for a normative work item) from a location that they are not familiar with. Specifically, if the IPR for any work item isn't clear (using language that has been agreed to by W3C Members), there is a strong chance that one or more AC Representatives will take issue with it (e.g., as a stall tactic), even to the point of raising a formal objection. In the very best case, they're going to ask the document author to track down everyone that contributed to that document and sign an IPR release for the draft before it can be pulled into the WG. This IPR uncertainty when W3C AC Members review our charter is all stuff that we should avoid as much as possible... it'll unnecessarily slow the work down.

W3C AC Reps understand W3C Community Group specification -> W3C Working Group specification. They raise their eyebrows at most anything else. We should avoid giving them targets to shoot at.

[OR13]

Being allowed to do something, and having it be a good idea are not the same thing.

I don't think the W3C CCG is somehow "better" than other places when it comes to links related to "Verifiable Credentials"... and I am not sure the AC Members would agree with your assertions, but your clarity does help.

[OR13]

I suggest we try our best to merge all these link PRs so the section can be reorganized... I am happy to do a PR to clean them up, but not with so many open PRs trying to add links.

[brentzundel]

@msporny Is this still a WIP? It has sufficient approvals that I would like to merge it.

[msporny]

@msporny Is this still a WIP? It has sufficient approvals that I would like to merge it.

We are still waiting on a co-sponsor in CCG for the work item. If the Chairs are ok with listing a work item that has not yet been accepted as a CCG work item (and under the W3C CCG IPR policy), then please merge away.

I expect this item to be either 1) accepted by the CCG, or 2) removed from the VCWG charter.

[OR13]

IMO, we should be accepting #51 and not this PR.

[OR13]

IMO, we should be handling these new key and signature representations consistently (for P-256, P-384, P-521) or not at all.

We should not be doing 1 offs for families like NIST curves.

[msporny]

IMO, we should be handling these new key and signature representations consistently (for P-256, P-384, P-521) or not at all.

That is why Data Integrity now covers doing exactly that for key formats (if the WG decides that they want to head in that direction): https://w3c-ccg.github.io/data-integrity-spec/#multikey

We should not be doing 1 offs for families like NIST curves.

If the WG wants to define a cryptosuite for NIST curve families, it can do that. Again, blocking an input document that would go into that conversation is probably not a way to ensure that all options are on the table.

[OR13]

@msporny seems like this PR title has been overtaken by events, are we already linking to https://w3c-ccg.github.io/data-integrity-spec/#multikey ?

Why do we need this PR if we can just link directly to that section?

[msporny]

Why do we need this PR if we can just link directly to that section?

Because there is no focused cryptosuite defined for ECDSA using secpr1. Yes, JsonWebSignature2020 exists, but it pulls in many other cryptosuites that could be viewed as not relevant to systems that only want to support ECDSA using secpr1.

The ECDSA secpr1 cryptosuite might support publicKeyJwk, publicKeyMultibase, AND publicKeyPem... or only publicKeyMultibase... or something else -- that's up to the WG to decide (if we decide to separate key formats from cryptosuites -- which would be a good thing, imho). At the same time, if we separate key formats from cryptosuites, where will publicKeyPgp live? Where do we define it?

In any case, this PR continues to exist for the reasons stated in the first paragraph above.

[OR13]

It feels like we are trying to do 2 things under this charter item:

1. define LD Proofs that rely on publicKeyMultibase and raw digital signatures
2. define LD Proofs that rely on publicKeyJwk and detached jws.

I support both of these things.

If the best we can do is point to a few different specs to speak to the desire to do multikey, that is the best we can do I suppose.

It feels like something like MultiCodecSignature2020 that supported Ed25519 and secp384r1 and others would be better than listing them one at a time.

[kdenhartog]

I don't see the relevance of a key format to the signature format. The VCWG should only be concerned with the way that the data model is used to attach a signature to the credential. It's up to the DID Core or other relevant key representation specs to define the key formats. It's easy enough to convert a public key and associated metadata without needing to couple it to the signature format. This coupling brings in unnecessary couplings in my opinion.

[OR13]

I have requested the link in this PR be updated to reflect the new home for the document.

[msporny]

I have requested the link in this PR be updated to reflect the new home for the document.

Done.

[brentzundel]

@msporny since this PR has broad approval and no requests for changes, we should merge it.
I leave it up to you to decide whether is makes sense to resolve the existing merge conflicts so that it can be merged or to simply close it in favor of PR #77

[kdenhartog]

Approving because this won't affect charter text in any actionable way. However since the topic has come up during charter discussion I'd argue that the WG should consider splitting out key formats from the suites when standardizing this work.

[OR13]

I replied to a similar comment here: #51 (comment)

[msporny]

@kdenhartog wrote:

Approving because this won't affect charter text in any actionable way. However since the topic has come up during charter discussion I'd argue that the WG should consider splitting out key formats from the suites when standardizing this work.

@OR13 wrote:

I replied to a similar comment here: #51 (comment)

I'm starting to feel like a broken record at this point, but just repeat myself again:

This is already contemplated in the Data Integrity spec: https://w3c-ccg.github.io/data-integrity-spec/#multikey

... and in the spec pointed to by this PR:

https://w3c-ccg.github.io/di-ecdsa-secpr1-2019/#example-a-multibase-encoded-multicodec-curve-p-384-public-key

https://w3c-ccg.github.io/di-ecdsa-secpr1-2019/#example-a-dataintegritysignature-example-using-a-nistecdsa2019-cryptosuite

The text clearly still needs work, but there is an expectation written in these input documents that we do plan to separate key format from cryptosuite in the general case, but still provide the option to specify key format in cryptosuites to support things like EthereumEip712Signature2020 (which doesn't have a JWK/JWS mapping, nor a Multikey mapping, and probably won't because it's more proof than signature). PGP falls into the same category of not having mappings in either JWK/JWS or Multikey. PEM, while having a JWK mapping (kinda sorta, but not really because many implementations do totally different things there) also falls into this category.

[msporny]

I leave it up to you to decide whether is makes sense to resolve the existing merge conflicts so that it can be merged or to simply close it in favor of PR #77

I'll close this PR after we merge #77.

[msporny]

PR #77 has been merged, which includes this change, closing.