Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace verificationMethods type in did:dht to use VerificationMethodSpec #146

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

andresuribe87
Copy link
Contributor

Overview

This PR makes the CreateDid{Dht,Ion}Options consistent, and allows users to create dht dids without having to worry about the key creation for the verification methods.

Description

See the updated DidDhtTest.kt file to understand how we allow consumers to create VerificationMethods with or without a KeyManager.

How Has This Been Tested?

Simple refactor. I just moved stuff around and slightly updated tests.

References

See the original did:ion PR that allowed this in #96

Copy link

codecov bot commented Nov 21, 2023

Codecov Report

Merging #146 (04c619c) into main (8fe7e59) will increase coverage by 0.00%.
Report is 1 commits behind head on main.
The diff coverage is 92.23%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #146   +/-   ##
=======================================
  Coverage   78.89%   78.89%           
=======================================
  Files          33       34    +1     
  Lines        1928     1933    +5     
  Branches      265      262    -3     
=======================================
+ Hits         1521     1525    +4     
- Misses        275      276    +1     
  Partials      132      132           
Components Coverage Δ
credentials 80.33% <ø> (ø)
crypto 38.07% <ø> (ø)
dids 89.55% <92.23%> (-0.05%) ⬇️
common 80.44% <ø> (ø)

@mistermoe
Copy link
Member

mistermoe commented Nov 22, 2023

@andresuribe87 does this change the public api surface? if so, as mentioned before, can you provide:

  • example of API surface prior to change
  • example of proposed change to API surface
  • rationale behind making said change

Comment on lines 87 to 88
public val verificationMethodsToAdd: Iterable<VerificationMethodSpec> = emptyList(),
public val servicesToAdd: Iterable<Service> = emptyList(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

toAdd seems redundant here given that these are create options.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was toAdd in CreateDidIonOptions already. Happy to change, but I think that should be part of a separate PR. Mind creating an issue?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i can create a separate issue for changing DidIon. DidDht was already just services and verificationMethods. We should keep it that way. no point in changing code to match what's going to be immediately changed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see what you mean. Fixed in c5b2eac

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And renamed to the existing didion to b24b9fd

* The [id] property cannot be over 50 chars and must only use characters from the Base64URL character set.
*/
public class JsonWebKey2020VerificationMethod(
public val id: String,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think this should be optional not required. default to jwk thumbprint if not provided

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was required before. What's the motivation behind not requiring it?

Regardless, I think that should be part of a separate PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Elaborating further, I don't think we should be adding for a couple of reasons. The id here is the verification method ID. It's not the id for the key. The key id for JWK is contained inside the publicKeyJwk parameter.

@andresuribe87
Copy link
Contributor Author

@andresuribe87 does this change the public api surface? if so, as mentioned before, can you provide:

  • example of API surface prior to change
  • example of proposed change to API surface
  • rationale behind making said change

The API surface before wasn't consistent across different implementations. This PR isn't introducing a new API, it's just standardizing. As such, I didn't consider this as needing to go through the normal process of proposing new public APIs. The existing API that this PR is moving the DHT implementation towards was discussed before doing merging in the DID ION implementation PR (#96). This PR is purposefully not proposing changing the existing public API used by Did Ion.

Just for clarity, I'm including answers here:

API before:

      val manager = InMemoryKeyManager()

      val otherKey = manager.generatePrivateKey(JWSAlgorithm.ES256K, Curve.SECP256K1)
      val publicKeyJwk = manager.getPublicKey(otherKey).toPublicJWK()
      val verificationMethodsToAdd: Iterable<Pair<JWK, Array<PublicKeyPurpose>>> = listOf(
        Pair(publicKeyJwk, arrayOf(PublicKeyPurpose.AUTHENTICATION, PublicKeyPurpose.ASSERTION_METHOD))
      )

      val serviceToAdd =
        Service.builder()
          .id(URI("test-service"))
          .type("HubService")
          .serviceEndpoint("https://example.com/service)")
          .build()

      val opts = CreateDidDhtOptions(
        verificationMethods = verificationMethodsToAdd, services = listOf(serviceToAdd), publish = false
      )
      val did = DidDht.create(manager, opts)

API after

      val manager = InMemoryKeyManager()

      val otherKey = manager.generatePrivateKey(JWSAlgorithm.ES256K, Curve.SECP256K1)
      val publicKeyJwk = manager.getPublicKey(otherKey).toPublicJWK()
      val verificationMethodsToAdd = listOf(
        JsonWebKey2020VerificationMethod(
          id = publicKeyJwk.keyID,
          publicKeyJwk = publicKeyJwk,
          relationships = listOf(PublicKeyPurpose.AUTHENTICATION, PublicKeyPurpose.ASSERTION_METHOD)
        ),
        VerificationMethodCreationParams(
          algorithm = JWSAlgorithm.EdDSA,
          curve = Curve.Ed25519,
          relationships = listOf(PublicKeyPurpose.ASSERTION_METHOD, PublicKeyPurpose.CAPABILITY_INVOCATION)
        ),
      )

      val serviceToAdd =
        Service.builder()
          .id(URI("test-service"))
          .type("HubService")
          .serviceEndpoint("https://example.com/service)")
          .build()

      val opts = CreateDidDhtOptions(
        verificationMethodsToAdd = verificationMethodsToAdd, servicesToAdd = listOf(serviceToAdd), publish = false
      )
      val did = DidDht.create(manager, opts)

Rationale

As explained in the PR description, CreateDidIonOptions already had a public API for adding verification methods and services to a did. This PR is making CreateDidDhtOptions use the same style, so it's consistent across different did methods.

@andresuribe87
Copy link
Contributor Author

@mistermoe let me know if I have addressed your concerns.

@@ -77,14 +79,14 @@ private class DidDhtApiImpl(configuration: DidDhtConfiguration) : DidDhtApi(conf

/**
* Specifies options for creating a new "did:dht" Decentralized Identifier (DID).
* @property verificationMethods A list of [JWK]s to add to the DID Document mapped to their purposes
* as verification methods.
* @property verificationMethods List of specs that will be added to the DID ION document. It's important to note
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* @property verificationMethods List of specs that will be added to the DID ION document. It's important to note
* @property verificationMethods List of verification methods that will be added to the DID DHT document. It's important to note

val verificationMethodsToAdd: Iterable<Pair<JWK, Array<PublicKeyPurpose>>> = listOf(
Pair(publicKeyJwk, arrayOf(PublicKeyPurpose.AUTHENTICATION, PublicKeyPurpose.ASSERTION_METHOD))
val verificationMethodsToAdd = listOf(
JsonWebKey2020VerificationMethod(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

noting that we should change this to just JsonWebKey TBD54566975/did-dht#60 TBD54566975/web5-spec#73

Comment on lines +106 to +123
DidDht.create(
manager,
CreateDidDhtOptions(
verificationMethods = listOf(
JsonWebKey2020VerificationMethod(
id = "0",
publicKeyJwk = manager.getPublicKey(
manager.generatePrivateKey(
JWSAlgorithm.EdDSA,
Curve.Ed25519
)
).toPublicJWK(),
relationships = listOf(PublicKeyPurpose.AUTHENTICATION)
)
),
publish = false
)
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm just not sure anyone would be able to figure out how to do this

Copy link
Contributor Author

@andresuribe87 andresuribe87 Dec 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mistermoe is there a concrete suggestion you have in mind?

This was my best approach towards having options such that:

  • The options between ion and Dht are consistent.
  • there is a way for consumers of the library to provide the JWK keys they want to be used within the did document.
  • there is a way for consumers to have the key creation handled for them.

Note that this had been discussed beforehand, when we added options to did ion. It made sense to me back then, and still make sense. So I'd be curious to understand further what differences you see between ion and dht.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants