-
Notifications
You must be signed in to change notification settings - Fork 10
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
base: main
Are you sure you want to change the base?
Conversation
Codecov Report
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
|
dids/src/main/kotlin/web5/sdk/dids/verificationmethods/VerificationMethod.kt
Show resolved
Hide resolved
@andresuribe87 does this change the public api surface? if so, as mentioned before, can you provide:
|
public val verificationMethodsToAdd: Iterable<VerificationMethodSpec> = emptyList(), | ||
public val servicesToAdd: Iterable<Service> = emptyList(), |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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) RationaleAs explained in the PR description, |
@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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* @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( |
There was a problem hiding this comment.
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
decentralized-identity/did-dht#60 decentralized-identity/web5-spec#73
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 | ||
) | ||
) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
Overview
This PR makes the
CreateDid{Dht,Ion}Options
consistent, and allows users to createdht
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 createVerificationMethods
with or without aKeyManager
.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