Re: Verifiable Conditions - implementation progress

yes, likely the decision to keep the type a single string is reflective of
a general concern Manu has raised many, many times...

It's dangerous to use the same key for multiple cryptographic operations
and purposes, or rather, it's a best practice to use separate key
material...

So for example, while you can do both ECDH and ES256 with P-256, you should
probably use 2 separate keys for key agreement and signatures.

That said, its fairly common to define a key that is mean to be used for
multiple purposes:

https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/importKey#parameters

note that "keyUsages" is an array, not a string.

Manu has strong opinions on this, which he has shared many times, but I
will invite him to share again.

For my part, I think that developers will simply ignore the LD semantics if
they get in the way of "cryptographic reality"...

so for example, P256VerificationKey2021 would likely be used for ECHD and
not created and registered as a separate type "P256KeyAgreementKey2021"

But you might assume this would happen according to the rules of did core
today:

{
  "@context": ["https://www.w3.org/ns/did/v1", "
https://w3id.org/security/suites/jws-2020/v1"],
  "id": "did:example:123",
  "authentication": [
    {
      "id": "#1",
      "type": "P256VerificationKey2021",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-256",
        "x": "Rm4aIgzpL8QoKoQFJylNLO-UO0jsyMvv1cvRw4IG53g",
        "y": "1_g1FvaQDVFeV2DpWz-uwysRTO-JlcWI1ewXfl41NwM"
      }
    }
  ],
  "keyAgreement": [
    {
      "id": "#2",
      "type": "P256KeyAgreementKey2021",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-256",
        "x": "Rm4aIgzpL8QoKoQFJylNLO-UO0jsyMvv1cvRw4IG53g",
        "y": "1_g1FvaQDVFeV2DpWz-uwysRTO-JlcWI1ewXfl41NwM"
      }
    }
  ]
}

Note the need to repeat the key content, because of the type issue.... vs:

{
  "@context": ["https://www.w3.org/ns/did/v1", "
https://w3id.org/security/suites/jws-2020/v1"],
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "#1",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-256",
        "x": "Rm4aIgzpL8QoKoQFJylNLO-UO0jsyMvv1cvRw4IG53g",
        "y": "1_g1FvaQDVFeV2DpWz-uwysRTO-JlcWI1ewXfl41NwM"
      }
    }
  ],
  "authentication": ["#1"],
  "keyAgreement": ["#1"]
}

It is worth noting that your "Signature Suite" can define support for
multiple types, even though normally there is a 1-1 mapping... so for
example, ES256K / JsonWebSignature2020 might use both
EcdsaSecp256k1VerificationKey2019 and JsonWebKey2020.

OS


On Tue, May 18, 2021 at 1:39 PM Markus Sabadello <markus@danubetech.com>
wrote:

> Well yes, all normative "MUST" statements in the specification are strict
> in the sense that the DID document would otherwise not be compliant.
>
> E.g. also see the test suite which would fail if the type was an array:
>
> https://github.com/w3c/did-test-suite/blob/main/packages/did-core-test-server/suites/did-core-properties/did-core-properties.js#L80
>
> But I have to admit I also failed to notice this while looking at the
> early Verifiable Conditions drafts....
>
> Markus
> On 18.05.21 19:48, Jack Tanner wrote:
>
> I also want to check about the DID-core requirement for only one type. Is
> this strict? I think Orie Steele suggested to use multiple types while we
> were drafting the spec, so maybe I have not understood something.
>
> Cheers,
> Jack
> ------------------------------
> *From:* Jack Tanner
> *Sent:* 18 May 2021 4:33 PM
> *To:* public-credentials@w3.org <public-credentials@w3.org>
> <public-credentials@w3.org>
> *Cc:* Manu Sporny <msporny@digitalbazaar.com> <msporny@digitalbazaar.com>;
> Caspar Roelofs <caspar@gimly.io> <caspar@gimly.io>; markus@danubetech.com
> <markus@danubetech.com> <markus@danubetech.com>
> *Subject:* Verifiable Conditions - implementation progress
>
> Hi
>
> Team Gimly is leading the implementation of the Verifiable Credentials
> standard <https://github.com/w3c-ccg/verifiable-conditions> as part of
> the EOSIO DID
> <https://github.com/Gimly-Blockchain/eosio-did-resolver/blob/c49d23b3053a174cb78e1b7704f2bd43f9be3ab4/src/resolver.ts#L80>.
> The standard specifies a new *verification method* type that looks like
> this:
>
> {
>     "id": "did:example:123",
>     "controller": "did:example:123",
> *    "type": ["VerifiableCondition", "VerifiableConditionAnd"],*
>     "verificationMethod": {...},
> }
>
>
> We think there may be a problem with the Verifiable Credentials standard
> <https://github.com/w3c-ccg/verifiable-conditions>, as the *type* property
> does not conform to the DID-core
> <https://w3c.github.io/did-core/#verification-methods> spec regarding the
> *type* property of *verification methods*:
>
> The value of the type property MUST be a string that references *exactly
> one verification method type*. In order to maximize global
> interoperability, the verification method type SHOULD be registered in the
> DID Specification Registries [DID-SPEC-REGISTRIES].
>
>
> As such, I propose that the Verifiable Condition is a single type, and
> that subtypes can be expressed like below. Please let me know what you
> think, especially @markus@danubetech.com <markus@danubetech.com> and @Manu
> Sporny <msporny@digitalbazaar.com>!
>
> {
>     "id": "did:example:123",
>     "controller": "did:example:123",
> *    "type": "VerifiableCondition",*
>     *"conditionType": ["VerifiableConditionAnd"],*
>     "verificationMethod": {...},
> }
>
>
> Cheers,
> Jack Tanner
>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>