microsoft / did-ccf

DID Method for the Confidential Consortium Framework (CCF)

W3C DID for Confidential Consortium Framework

Repository specifying a W3C DID-Core method for building decentralized identifier networks on top of CCF. This repositorty also includes a CCF application (Typescript) implementation for generating new identifiers, resolving identifiers and maintaining identifiers and their associated cryptographic keys.

Third-party components

We rely on several open source third-party components, attributed under THIRD_PARTY_NOTICES.

Contributing

This project welcomes contributions and suggestions. Please see the Contribution guidelines.

did-ccf's Issues

Use relative DID URLs in the controller document

Is your feature request related to a problem? Please describe.
The controller documents currently contains fully qualified id's such as did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:9EKMeln_Cf6AETnzNduACdZpGTJ4KvnPDLhFY1S0nuk#p4U5jGNxVwia. By including an identifier base and switching to relative URLs such as #p4U5jGNxVwia, document size can be reduced.

Describe the solution you'd like
The current documents generated:

{
    "id": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:9EKMeln_Cf6AETnzNduACdZpGTJ4KvnPDLhFY1S0nuk",
    "verificationMethod": [
        {
            "id": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:9EKMeln_Cf6AETnzNduACdZpGTJ4KvnPDLhFY1S0nuk#puHbzqkQbjN1",
            "controller": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:9EKMeln_Cf6AETnzNduACdZpGTJ4KvnPDLhFY1S0nuk",
            "type": "JsonWebKey2020",
            "publicKeyJwk": {
                "crv": "Ed25519",
                "kid": "#puHbzqkQbjN1",
                "kty": "OKP",
                "x": "w327SXx4WN5aRQ3Vb7cH64ZHx8pTrFYLMUqRqmTGc8A"
            }
        },
        {
            "id": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:9EKMeln_Cf6AETnzNduACdZpGTJ4KvnPDLhFY1S0nuk#p4U5jGNxVwia",
            "controller": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:9EKMeln_Cf6AETnzNduACdZpGTJ4KvnPDLhFY1S0nuk",
            "type": "JsonWebKey2020",
            "publicKeyJwk": {
                "crv": "Ed25519",
                "kid": "#p4U5jGNxVwia",
                "kty": "OKP",
                "x": "YcE5uHJk07w6lGs7_ym5bU7qmsVOVl_6ZIrTpsvhWTk"
            }
        }
    ],
    "@context": [
        "https://www.w3.org/ns/did/v1",
        "https://w3id.org/security/suites/jws-2020/v1",
        {
            "@vocab": "https://github.com/microsoft/did-ccf/blob/main/DID_CCF.md#"
        }
    ],
    "authentication": [
        "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:9EKMeln_Cf6AETnzNduACdZpGTJ4KvnPDLhFY1S0nuk#puHbzqkQbjN1"
    ],
    "assertionMethod": [
        "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:9EKMeln_Cf6AETnzNduACdZpGTJ4KvnPDLhFY1S0nuk#puHbzqkQbjN1"
    ],
    "keyAgreement": [
        "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:9EKMeln_Cf6AETnzNduACdZpGTJ4KvnPDLhFY1S0nuk#p4U5jGNxVwia"
    ],
    "service": [
        {
            "id": "#linkeddomain",
            "type": "LinkedDomains",
            "serviceEndpoint": "https://www.vcsatoshi.com/"
        }
    ]
}

Document generated if proposed feature is implemented:

{
  "id": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:9EKMeln_Cf6AETnzNduACdZpGTJ4KvnPDLhFY1S0nuk",
  "verificationMethod": [
    {
      "id": "#puHbzqkQbjN1",
      "controller": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:9EKMeln_Cf6AETnzNduACdZpGTJ4KvnPDLhFY1S0nuk",
      "type": "JsonWebKey2020",
      "publicKeyJwk": {
        "crv": "Ed25519",
        "kid": "#puHbzqkQbjN1",
        "kty": "OKP",
        "x": "w327SXx4WN5aRQ3Vb7cH64ZHx8pTrFYLMUqRqmTGc8A"
      }
    },
    {
      "id": "#p4U5jGNxVwia",
      "controller": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:9EKMeln_Cf6AETnzNduACdZpGTJ4KvnPDLhFY1S0nuk",
      "type": "JsonWebKey2020",
      "publicKeyJwk": {
        "crv": "Ed25519",
        "kid": "#p4U5jGNxVwia",
        "kty": "OKP",
        "x": "YcE5uHJk07w6lGs7_ym5bU7qmsVOVl_6ZIrTpsvhWTk"
      }
    }
  ],
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1",
    {
      "@base": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:9EKMeln_Cf6AETnzNduACdZpGTJ4KvnPDLhFY1S0nuk"
    },
    {
      "@vocab": "https://github.com/microsoft/did-ccf/blob/main/DID_CCF.md#"
    }
  ],
  "authentication": [
    "#puHbzqkQbjN1"
  ],
  "assertionMethod": [
    "#puHbzqkQbjN1"
  ],
  "keyAgreement": [
    "#p4U5jGNxVwia"
  ],
  "service": [
    {
      "id": "#linkeddomain",
      "type": "LinkedDomains",
      "serviceEndpoint": "https://www.vcsatoshi.com/"
    }
  ]
}

Identifier#controller or #controllerDelegate unreliable under key rotation

Describe the bug
Identifiers are tied to the id of an AuthenticatedIdentity, but this id in turn is the digest of that entity's public key. If the entity rotates their cert/key pair, then they could lose access to Identifiers of which they are either the controller or the delegate controller, c.f.

did-ccf/src/models/Identifier.ts

Line 42 in c375752

return (authenticatedIdentity.identifier === this.controller ||

To Reproduce

• Add a member or user to a consortium
• Create one more more Identifiers with the entity (or on their behalf).
• Rotate the entity's key
• Try and perform an authenticated operation with any or all of the Identifiers created with or on behalf of the entity

Expected behavior
A user or member should be able to access their Identifiers subsequent to any number of key rotations

Add user input validation

Is your feature request related to a problem? Please describe.
The current APIs don't perform user input validation, but instead fallback to default values.

Describe the solution you'd like
The APIs should perform user input validation and return a 4xx error to the caller to prevent unexpected behavior.

ECDSA signature verification fails

Describe the bug
Signature verification fails when using ECDSA keys, either SECP356R1 or SECP256K1. RSA and EdDSA based keys verify as expected.

To Reproduce
Execute the following commands replacing 'node' with the target host, 'identifier' with the network identifier created with ECDSA keys. Follow standard CCF member authentication for 'service_cert', 'signing_key_pem' and 'signing_cert_pem'.

./scurl.sh https://<node>/app/identifiers/<identifier/signature/sign --cacert <service_cert> --signing-key <signing_key_pem> --signing-cert <signing_cert_pem> -H "content-type: plain/text" --data "Text to sign" -X POST | jq

./scurl.sh https://<node>/app/identifiers/<identifier>/signature/sign --cacert <service_cert> --signing-key <signing_key_pem> --signing-cert <signing_cert_pem> -H "content-type: plain/text" -d '{"payload":"Text to sign","signer":"<identifier>", "signature":"<signature>"}' -X POST

Expected behavior
Signature verification should return true.

Convert from public JWK to PEM

Is your feature request related to a problem? Please describe.
Signatures using a public key provided via verification method in a controller document, need to be converted from JWK to it's PEM representation in order for the underlying crypto implementation to verify. Because there is no current mechanism for doing this conversion the verify service is unable to verify signatures based on controller documents

Describe the solution you'd like
Keypair.ts implements an abstract static method - fromJwk() - which is implemented by derived classes that converts the JWK into an instance of KeyPair which includes the public PEM.

Incorrect identifier format for JWK

Describe the bug
The kid of the JWKs included in the controller document incorrectly includes the # which is used by relative DID URLs. This should be removed.

To Reproduce

"publicKeyJwk": {
    "crv": "Ed25519",
    "kid": "#p4U5jGNxVwia",
    "kty": "OKP",
    "x": "YcE5uHJk07w6lGs7_ym5bU7qmsVOVl_6ZIrTpsvhWTk"
}

Expected behavior

"publicKeyJwk": {
    "crv": "Ed25519",
    "kid": "p4U5jGNxVwia",
    "kty": "OKP",
    "x": "YcE5uHJk07w6lGs7_ym5bU7qmsVOVl_6ZIrTpsvhWTk"
}

Enable users to create, and use, DIDs on their own behalf

Is your feature request related to a problem? Please describe.
Only members can create DIDs, and perform operations with them, on behalf of users.

Describe the solution you'd like
Add user_signature to the list of authentication policies on endpoints through which DIDs are created and used.

Services in Controller Document

The W3C DID Core specification defines a mechanism to express ways of communicating with the DID subject or associated entities. A service can be any type of service the DID subject wants to advertise, including decentralized identity management services for further discovery, authentication, authorization, or interaction.

 "service": [
      {
        "id": "#linkeddomains",
        "type": "LinkedDomains",
        "serviceEndpoint": {
          "origins": [
            "https://www.vcsatoshi.com/"
          ]
        }
      }
    ],

This mechanism is widely supported in the community to express Linked domains, status lists etc. In order to be interoperable with community efforts, DID-CCF should support the adding and removing of services from the controller document.

Signature verification restricted to DID document controller(s)

Describe the bug
Only the registered controller of a DID document, or their delegate, can use a DID to verify signatures generated by the corresponding keys in CCF's key/value store. It seems likely that parties other than the document controller will want to be able to verify signatures with a given DID not under their control.

To Reproduce

• Install did_ccf
• Using one member, create a new DID
• Using the same member, sign an arbitrary payload with the identifier returned in the previous step
• Using a different member, attempt to verify the signature with the same identifier

Expected behavior
That a valid signature could be verified by some party other than the DID document's controller, or their delegate.

Environment information
CCF 3.0.5 with 2+ members.

Copyright Headers

Describe the bug
All files should include the default Microsoft copyright header.

To Reproduce
Steps to reproduce the behavior.

Expected behavior
The following Copyright header is present at the top of each code file.
// Copyright (c) Microsoft Corporation. All rights reserved.
// Licensed under the Apache 2.0 License.

Support specifying different algorithms for signing and encrypting

Is your feature request related to a problem? Please describe.
The Create API currently use the same algorithm specified in the query to create the signing and encryption keys.

Describe the solution you'd like
Allow the API caller to specify different algorithms to use for signature vs encryption. Alternatively since only ECDSA, EdDSA and RSA are supported, create the signing key with the algorithm specified and use RSA for the encryption key as the 2 other are DSA algorithms.

Signing API forwarding unnecessarily to all nodes

Describe the bug
The signing and verifying APIs currently have forwarding_required always in their OpenAPI definitions in app.json.

This has performance and scalability issues. Given that both operations only read from the network forwarding is not required and should be changed to never.

To Reproduce

"forwarding_required": "always",

Expected behavior

"forwarding_required": "never",

Non-conformant controller document

Describe the bug
A number of properties in the controller document are not conformant with the latest iteration of the W3C DID-Core specification:

• Using JsonWebKey2020 requires additional context import
• VerificationMethod id needs to be fully qualified with the controller identifier
• Missing assertion relationship

To Reproduce
This resolves to controller document below

{
  "id": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:K3AuyyQ5sNaebyw_R5QzAPZ3mNXuaL_6fipxsLZsRKE",
  "verificationMethod": [
    {
      "id": "#kJxrPjmfnG2i",
      "controller": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:K3AuyyQ5sNaebyw_R5QzAPZ3mNXuaL_6fipxsLZsRKE",
      "type": "JsonWebKey2020",
      "publicKeyJwk": {
        "crv": "Ed25519",
        "kid": "#kJxrPjmfnG2i",
        "kty": "OKP",
        "x": "XI8cY7TgH-aRopK4M1H2PvTXoiLBZ-tGrMw1OXdGTT4"
      }
    },
    {
      "id": "#Vsb600MTSTol",
      "controller": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:K3AuyyQ5sNaebyw_R5QzAPZ3mNXuaL_6fipxsLZsRKE",
      "type": "JsonWebKey2020",
      "publicKeyJwk": {
        "crv": "Ed25519",
        "kid": "#Vsb600MTSTol",
        "kty": "OKP",
        "x": "A5TBodVXwP8ON4blrw-4Hym3Gg6koGYVFqh1gX1670I"
      }
    }
  ],
  "@context": [
    "https://www.w3.org/ns/did/v1",
    {
      "@vocab": "https://github.com/microsoft/did-ccf/blob/main/DID_CCF.md#"
    }
  ],
  "authentication": [
    "#kJxrPjmfnG2i"
  ],
  "keyAgreement": [
    "#Vsb600MTSTol"
  ]
}

Expected behavior

{
  "id": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:K3AuyyQ5sNaebyw_R5QzAPZ3mNXuaL_6fipxsLZsRKE",
  "verificationMethod": [
    {
      "id": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:K3AuyyQ5sNaebyw_R5QzAPZ3mNXuaL_6fipxsLZsRKE#kJxrPjmfnG2i",
      "controller": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:K3AuyyQ5sNaebyw_R5QzAPZ3mNXuaL_6fipxsLZsRKE",
      "type": "JsonWebKey2020",
      "publicKeyJwk": {
        "crv": "Ed25519",
        "kid": "#kJxrPjmfnG2i",
        "kty": "OKP",
        "x": "XI8cY7TgH-aRopK4M1H2PvTXoiLBZ-tGrMw1OXdGTT4"
      }
    },
    {
      "id": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:K3AuyyQ5sNaebyw_R5QzAPZ3mNXuaL_6fipxsLZsRKE#Vsb600MTSTol",
      "controller": "did:ccf:exp-did-ccf-4.confidential-ledger.azure.com:K3AuyyQ5sNaebyw_R5QzAPZ3mNXuaL_6fipxsLZsRKE",
      "type": "JsonWebKey2020",
      "publicKeyJwk": {
        "crv": "Ed25519",
        "kid": "#Vsb600MTSTol",
        "kty": "OKP",
        "x": "A5TBodVXwP8ON4blrw-4Hym3Gg6koGYVFqh1gX1670I"
      }
    }
  ],
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1",
    {
      "@vocab": "https://github.com/microsoft/did-ccf/blob/main/DID_CCF.md#"
    }
  ],
  "assertionMethod": [
    "#kJxrPjmfnG2i"
  ],
  "authentication": [
    "#kJxrPjmfnG2i"
  ],
  "keyAgreement": [
    "#Vsb600MTSTol"
  ]
}

Potentially non-unique AuthenticatedIdentity under JWT Auth

Describe the bug
Callers who elect to authenticate via JWT are identified by the JWT's issuerKey which may not be unique to any given caller, c.f.

did-ccf/src/models/AuthenticatedIdentity.ts

Line 58 in 560274c

return (<JwtAuthnIdentity>identity).jwt.keyIssuer;

Expected behavior
Authenticated identities to be unique per entity regardless of the auth mechanism

Additional context
Thanks to @achamayou for pointing this out.