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

Removing did-common-java dependency #248

Merged
merged 37 commits into from
Mar 6, 2024
Merged

Conversation

jiyoonie9
Copy link
Contributor

@jiyoonie9 jiyoonie9 commented Feb 16, 2024

Overview

Introducing our own types for DID and related things like DIDDocument, Service, VerificationMethod, etc, and ejecting from did-common-java dependency. Some refactoring of DidDht implementation.

Blocked from merging by updates to web5-spec test vectors that also changed TBD54566975/web5-spec#118

Description

Motivation (per original issue)

Not published to maven central. consumers have to add danubetech's repository

introduces CVEs (though this may have been remedied in more recent versions)

heavy on JSON-LD

Follow up tasks

  • Rename Did abstract class to BearerDid

Note

DidUri name in this PR is temporary - will be changed back to Did after above renaming. See #254

  • Refactor DidDht

How Has This Been Tested?

  • Wrote tests for newly added types such as DIDDocument
  • Ensured all existing tests pass

Checklist

Before submitting this PR, please make sure:

  • I have read the CONTRIBUTING document.
  • My code is consistent with the rest of the project
  • I have tagged the relevant reviewers and/or interested parties
  • I have updated the READMEs and other documentation of affected packages

References

https://www.w3.org/TR/did-core/
https://github.com/TBD54566975/web5-go/tree/main/dids

dids/build.gradle.kts Outdated Show resolved Hide resolved
…jsonldobject inherited methods from did common java. replacing didurl with a verificationMethodId splitting on #
…did methods inherit from, and the new DID type
… specific methods in favor of the generic one
@jiyoonie9
Copy link
Contributor Author

jiyoonie9 commented Feb 26, 2024

blocker: need to merge TBD54566975/web5-spec#118 and pull in latest

@jiyoonie9 jiyoonie9 changed the title removing did common java dep Removing did-common-java dependency Feb 28, 2024
@@ -82,7 +83,7 @@ formatting:
MaximumLineLength:
active: true
ImportOrdering:
active: true
active: false
Copy link
Contributor Author

Choose a reason for hiding this comment

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

with this true, i cannot order import in a way that makes detekt happy. detekt does not like how Square style formatter in intellij does import ordering :(

Copy link
Member

@mistermoe mistermoe left a comment

Choose a reason for hiding this comment

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

great work @jiyoontbd! i know the effort required here was significant and that it's the first of a few PRs needed to get the dids package to parity with our SDKs

import java.security.SignatureException

/**
* DIDDocument represents a set of data describing the DID subject including mechanisms such as:
Copy link
Contributor

Choose a reason for hiding this comment

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

Idea: maybe link to the spec doc? https://www.w3.org/TR/did-core/#core-properties

}

/**
* Adds Controllers.
Copy link
Contributor

Choose a reason for hiding this comment

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

Might be better to use the word "Sets" rather than "Adds" as with arrays/lists "Add" may be confused with append or concat

package web5.sdk.dids.didcore

/**
* Contains metadata about the DID document.
Copy link
Contributor

Choose a reason for hiding this comment

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

/**
* Service is used in DID documents 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.
Copy link
Contributor

Choose a reason for hiding this comment

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

again, another spec link? https://www.w3.org/TR/did-core/#services

Copy link
Contributor

Choose a reason for hiding this comment

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

oh I see you're linking to the spec in the @property comment below (and that may have been true to previous comments) ... do whatevs you think is best, I'm moving quickly

return type == this.type
}

override fun toString(): String {
Copy link
Contributor

Choose a reason for hiding this comment

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

@jiyoontbd do you think we should introduce toJSON() functions on all of these types? I know we have dids/src/main/kotlin/web5/sdk/dids/Json.kt but another idea would be to add the JSON functionality to each DID type, to-and-from JSON strings. idk just a random thought I figured worth considering

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i think for now i'd like to just have Json.kt i sniped from tbdex-kt to do all the stringify work instead of distributing it to be for each type

Copy link
Contributor

Choose a reason for hiding this comment

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

😎 👍

* Utl methods for DIDs.
*
*/
public object DidUtil {
Copy link
Contributor

Choose a reason for hiding this comment

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

I generally a little allergic to anything named "utility" because it's a bit amorphous in my mind

What is a SimpleDid? It may warrant it's own place in the code base next to PortableDid and BearerDid? (doesn't need to be addressed here, food for thought)

Copy link
Contributor

Choose a reason for hiding this comment

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

(which I know PortableDid and BearerDid aren't here yet, so looking ahead)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

actually i don't have to use this class or its methods anymore

i can use DidUri instead of SimpleDid!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i also dislike utility anything but alas my brainjuice had ran out by the time i wrote this

import web5.sdk.dids.didcore.DidDocumentMetadata

/**
* Did document metadata for did:dht that extends the base did document metadata.
Copy link
Contributor

Choose a reason for hiding this comment

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

again, links to spec?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmm, i can't seem to find where type is defined in did dht document spec - @decentralgabe ? best i can find is https://did-dht.com/#type-indexing but that's about how to use types, not where types are defined in the did dht doc metadata section

.id(URI(did))
.verificationMethod(verificationMethod)
val didDocumentBuilder = DIDDocument.Builder()
.context("https://www.w3.org/ns/did/v1")
Copy link
Contributor

Choose a reason for hiding this comment

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

since "https://www.w3.org/ns/did/v1" is always to be included in a DID Document we could encapsulate that within the DIDDocument abstraction

Copy link
Member

Choose a reason for hiding this comment

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

the spec is confusing here, but this is not the case. the section you pointed to is for JSON-LD; however, there is a section above on a pure JSON representation that does not have this restriction.

for DID DHT I've chosen to follow the JSON representation and explicitly excluded the context property

Copy link
Contributor

Choose a reason for hiding this comment

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

nice!

* @property capabilityInvocation specifies a verification method used by the DID subject to invoke a
* cryptographic capability, such as the authorization to update the DID Document.
*/
public class DIDDocument(
Copy link
Contributor

@KendallWeihe KendallWeihe Mar 5, 2024

Choose a reason for hiding this comment

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

In some places we have DidDocument casing and other places (like here) we have DIDDocument casing. Any plans to make consistent?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

you probably saw DidDocumentMetadata - i changed that to DIDDocumentMetadata to make it consistent, ty!

@@ -136,15 +136,17 @@ class DhtTest {
inner class DhtTest {
@Test
fun `create and parse a bep44 put request`() {
print("WITCHCRAFT")
Copy link
Contributor

Choose a reason for hiding this comment

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

🧙‍♀️

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ehehehe


require(did.didDocument != null)

val kid = did.didDocument!!.verificationMethods?.first()?.publicKeyJwk?.get("kid")?.toString()
val kid = did.didDocument!!.verificationMethod?.first()?.publicKeyJwk?.keyID?.toString()
Copy link
Contributor

Choose a reason for hiding this comment

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

just noticing casing on keyID here as opposed to keyId, does Kotlin have an idiomatic casing style?

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. that's from the nimbusdssd JWK library that provides that field with the casing. we are going to also roll our own JWK so i'll keep that in mind when i'm working on that issue

Copy link
Contributor

@KendallWeihe KendallWeihe left a comment

Choose a reason for hiding this comment

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

added comments but nothing blocking, well done!

"id": "did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJYMjU1MTkiLCJ1c2UiOiJlbmMiLCJ4IjoiM3A3YmZYdDl3YlRUVzJIQzdPUTFOei1EUThoYmVHZE5yZngtRkctSUswOCJ9",
"verificationMethod": [
{
"id": "did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJYMjU1MTkiLCJ1c2UiOiJlbmMiLCJ4IjoiM3A3YmZYdDl3YlRUVzJIQzdPUTFOei1EUThoYmVHZE5yZngtRkctSUswOCJ9#0",
"type": "JsonWebKey2020",
"type": "JsonWebKey",
Copy link
Member

Choose a reason for hiding this comment

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

I believe this should be reverted, but practically it doesn't matter as long as we're internally consistent

the original did jwk spec was created before the JsonWebKey type existed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yea. i did this coz i thought we were internally moving towards aligning on JsonWebKey, so i changed the type for verificationmethod of DidJwk during resolve() to be JsonWebKey - https://github.com/TBD54566975/web5-kt/pull/248/files#diff-5537230f4c2b63c726999e7c345be0afee8bad05f7d49154d9897013f550ae7aR152

should i keep it as JsonWebKey2020? then i can revert this change.

@jiyoonie9 jiyoonie9 merged commit 2e4946d into main Mar 6, 2024
5 of 7 checks passed
@jiyoonie9 jiyoonie9 deleted the 185-replace-did-common-java branch March 6, 2024 01:27
@jiyoonie9 jiyoonie9 linked an issue Mar 11, 2024 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants