-
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
Removing did-common-java
dependency
#248
Conversation
…iddoc verif method and service types
…jsonldobject inherited methods from did common java. replacing didurl with a verificationMethodId splitting on #
…questions as todos
…did methods inherit from, and the new DID type
… specific methods in favor of the generic one
blocker: need to merge TBD54566975/web5-spec#118 and pull in latest |
…e-did-common-java
… reference. in the middle of refactoring did dht slightly. only 7-8 tests failing now...
…g. making verificationMethod a set to avoid duplication. 1 test remains to be fixed
did-common-java
dependency
@@ -82,7 +83,7 @@ formatting: | |||
MaximumLineLength: | |||
active: true | |||
ImportOrdering: | |||
active: true | |||
active: 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.
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 :(
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.
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
credentials/src/test/kotlin/web5/sdk/credentials/VerifiableCredentialTest.kt
Show resolved
Hide resolved
import java.security.SignatureException | ||
|
||
/** | ||
* DIDDocument represents a set of data describing the DID subject including mechanisms such as: |
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.
Idea: maybe link to the spec doc? https://www.w3.org/TR/did-core/#core-properties
} | ||
|
||
/** | ||
* Adds Controllers. |
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.
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. |
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.
maybe link to spec? https://www.w3.org/TR/did-core/#did-document-metadata
/** | ||
* 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. |
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.
again, another spec link? https://www.w3.org/TR/did-core/#services
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.
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 { |
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.
@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
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 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
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.
😎 👍
* Utl methods for DIDs. | ||
* | ||
*/ | ||
public object DidUtil { |
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 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)
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.
(which I know PortableDid
and BearerDid
aren't here yet, so looking ahead)
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.
actually i don't have to use this class or its methods anymore
i can use DidUri instead of SimpleDid!
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 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. |
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.
again, links to spec?
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.
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") |
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.
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
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.
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
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.
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( |
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.
In some places we have DidDocument
casing and other places (like here) we have DIDDocument
casing. Any plans to make consistent?
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.
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") |
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.
🧙♀️
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.
ehehehe
|
||
require(did.didDocument != null) | ||
|
||
val kid = did.didDocument!!.verificationMethods?.first()?.publicKeyJwk?.get("kid")?.toString() | ||
val kid = did.didDocument!!.verificationMethod?.first()?.publicKeyJwk?.keyID?.toString() |
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.
just noticing casing on keyID
here as opposed to keyId
, does Kotlin have an idiomatic casing style?
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. 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
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.
added comments but nothing blocking, well done!
"id": "did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJYMjU1MTkiLCJ1c2UiOiJlbmMiLCJ4IjoiM3A3YmZYdDl3YlRUVzJIQzdPUTFOei1EUThoYmVHZE5yZngtRkctSUswOCJ9", | ||
"verificationMethod": [ | ||
{ | ||
"id": "did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJYMjU1MTkiLCJ1c2UiOiJlbmMiLCJ4IjoiM3A3YmZYdDl3YlRUVzJIQzdPUTFOei1EUThoYmVHZE5yZngtRkctSUswOCJ9#0", | ||
"type": "JsonWebKey2020", | ||
"type": "JsonWebKey", |
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 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
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.
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.
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)
Follow up tasks
Did
abstract class toBearerDid
Note
DidUri
name in this PR is temporary - will be changed back toDid
after above renaming. See #254DidDht
How Has This Been Tested?
Checklist
Before submitting this PR, please make sure:
References
https://www.w3.org/TR/did-core/
https://github.com/TBD54566975/web5-go/tree/main/dids