Explain RsaSignature2018

[AxelNennker]

Please explain and spec RsaSignature2018. What does it mean that the proofType has this value?

The same for RsaVerificationKey2018, please.

As long as these values appear only in examples and non-normative text they can mean anything.

[Drabiv]

Please, also add explanation or point to spec for EcdsaKoblitzSignature2016 (2017, 2018).

[msporny]

Horribly out of date specs are here: https://w3c-dvcg.github.io/ld-signatures/ and here: https://w3c-dvcg.github.io/lds-rsa2018/

The proofPurpose stuff is very new (based on the recent consensus in the community around cryptographic suites).

EcdsaKoblitzSignature2016 is an experimental implementation that the Bitcoin/Ethereum devs are playing around with: https://w3c-dvcg.github.io/lds-koblitz2016/

Again, all those specs need to be revved to catch up with where implementations are currently. I'll non-normatively link to the appropriate specs in the DID spec.

[Drabiv]

Thanks, for links @msporny. It would be really good to have Koblitz 2017 or 2018 suite updated with proof and proofType properties.

[msporny]

It would be really good to have Koblitz 2017 or 2018 suite updated with proof and proofType properties.

"proof" will move into Linked Data Signatures (which Koblitz is built on top of). Same for "proofType", so no update to Koblitz will be necessary and it'll seem as if "proof" and "proofPurpose" existed back in 2016. Yes, this is a strange way to do things, but we don't think it will lead to issues in deployed systems. If that turns out to not be true, we'll update Koblitz to 2018 to include "proof" and "proofPurpose".

[Drabiv]

OK. Actually, what I am trying to ask, get clarity on is – "What value should be set into proofType when I sign credential using Ethereum or Bitcoin standard tools (meaning ECDSA secp256k1 signing algorithm; Keccak-256 hashing algorithm?"

[msporny]

What value should be set into proofType when I sign credential using Ethereum or Bitcoin standard tools (meaning ECDSA secp256k1 signing algorithm; Keccak-256 hashing algorithm?

proofPurpose is meant to contain the cryptographic suite that is associated with the key that is doing the signing. If you're in the DID ecosystem, the only valid value for "proofPurpose" at present is "authentication".

For the Veres One DID Method, you can also have "invokeCapability" and "grantCapability", which are currently being renamed to something else.

In the future, I expect "messageEncryption" or "encryption" to also be a valid value for proofType.

[dlongley]

Also, the term is "proofPurpose" not "proofType". If we have "proofType" in a spec somewhere it needs to be updated.

[Drabiv]

OK, I am confused now. Please see following examples of proofTypes in different specs ("RsaSignature2018", "LinkedDataSignature2015", "EcdsaKoblitzSignature2016"): https://w3c.github.io/vc-data-model/#proofs-aka-signatures https://w3c-ccg.github.io/did-spec/#proof-optional https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/8ac6e0d7e522da2f9e852fc2c04efd2bd67c8141/draft-documents/introducing_btcr.md

If these needs to be changed to "authentication" then please clarify what value should be set for public key type that is used for signing credentials and/or authentication and/or encryption? Also, what should be populated into proofType for keys that are authorization keys in DD and not authentication keys?

[dlongley]

@Drabiv,

The confusion is that when you say "proofType" you mean "proof.type", i.e. the "type" property of a proof. That's not what @msporny and I were talking about, we're talking about a literal property called "proofPurpose". As an example:

"proof": {
    "type": "RsaSignature2018",
    "created": "2017-06-18T21:19:10Z",
    "creator": "https://example.com/jdoe/keys/1",
    "proofPurpose": "authentication",
    "nonce": "c0ae1c8e-c7e7-469f-b252-86e6a0e7387e",
    "jws": "BavEll0...W3JT24"
  }

The "proof.type" is "RsaSignature2018". The "proofPurpose" is "authentication". This means that the type of proof is an RSA signature according to the "RsaSignature2018" signature suite -- and its purpose (why the author created the signature) is for authentication.

[dlongley]

To further elaborate, a signature author would specify different keys for different purposes in their DID document:

{
  "id": "did:method1:1234",
  "authentication": [{
    "type": "RsaSignatureAuthentication2018",
    "publicKey": [{
      "id": "did:method1:1234#auth-key-1",
      "type": "RsaVerificationKey2018",
      "owner": "did:method1:1234",
      "publicKeyPem": "..."
    }, ...]
  }, ...],
  "invokeCapability": [{
    "type": "RsaSignatureAuthentication2018",
    "publicKey": [{
      "id": "did:method1:1234#ocap-key-1",
      "type": "RsaVerificationKey2018",
      "owner": "did:method1:1234",
      "publicKeyPem": "..."
    }, ...]
  }, ...]
}

And then signature validators would take the signature that an author created, find its key and its purpose, and ensure the key owner's DID Document lists the key underneath the purpose.

[Drabiv]

All right, got it. Thanks @dlongley! I guess, I confused apples with oranges. Sorry, about that. But while on this topic, now if I understood correctly - when I use Bitcoin/Ethereum algos for signing, I should set "proof.type" value to "EcdsaKoblitzSignature2016" . So back to my question original request:

It would be really good to have Koblitz 2017 or 2018 suite updated with proof and proofType properties.

What I meant is to have Koblitz signature suite specs (https://w3c-dvcg.github.io/lds-koblitz2016/) updated to allow "proof" and "proof.type" properties, so that they are compliant with VC spec (https://w3c.github.io/vc-data-model/#proofs-aka-signatures)

[dlongley]

@Drabiv,

Yes, it would be nice to get the koblitz signature suite updated -- see related:

https://lists.w3.org/Archives/Public/public-credentials/2018Mar/0008.html

[Drabiv]

Thanks @dlongley. I've checked https://w3id.org/security/v2 and it does not have description of EcdsaKoblitzSignature2016, so I guess it will be not correct to use it as context for "proof.type" = "EcdsaKoblitzSignature2016" I'd make PR to change spec myself, but I am too inexperienced with these specs for now, to try doing this.

[AxelNennker]

How about not specifying signature schemes in did-spec at all but referring to a registry of currently known signatures and leaving the details to the implementations?

Like OAuth2 is an authentication framework and does not define the format of access tokens. (Although there is a close relationship between OAuth2 AZ and resource server...)

This approach is maybe not the best for interoperability...

Or refer to the registry in all places where a signature is needed.

[msporny]

How about not specifying signature schemes in did-spec at all but referring to a registry of currently known signatures and leaving the details to the implementations?

Yes, this is exactly what the current plan is... just haven't had the spare cycles to update the specs to align with the plan. That said, people have been complaining about lack of examples, so we have to include /something/. All examples are non-normative, so we shouldn't have an issue there.

[dlongley]

@Drabiv,

https://w3id.org/security/v2 pulls in https://w3id.org/security/v1 ... so it will include EcdsaKoblitzSignature2016.

[kimdhamilton]

Question: should this issue be moved to a CCG repo?

I think the only action item for the DID spec itself is ensuring the samples are up to date (if not already)

[AxelNennker]

Somebody willing to add all these algs to JWA ?

[jandrieu]

Closing as we have adopted this issue in the new DIDWG repo.

[AxelNennker]

Closing as we have adopted this issue in the new DIDWG repo.

A link to the new issue would be nice here

[msporny]

@AxelNennker, now included (see above).