decentralized-identity / did-common-java Goto Github PK

what is the purpose of this uri linked domain?

Can you tell the instruction for building this project.

This and the other universal-resolver-java maven projects look pretty complete. Could they be published to a public repository, so we can reference them in our own projects?

Hey there, first off, thank you to the maintainers of this library. We're leveraging it in one of our backend services and it works great!

Would it be possible for y'all to upload/mirror this JAR to maven central? We're gearing up to deploy our backend service but are unable to pull the dependency within our internal network unless we go through a laborious vendor security process. I imagine that other companies have similar processes in place as well. Myself and potentially many other devs would be very grateful for the time savings!

If y'all decide to do so, here's a link with instructions on how to publish to maven central for free - https://www.jetbrains.com/help/space/publish-artifacts-to-maven-central.html

If it's too much of a lift, no worries. Thanks in advance!

running into the following error when calling verificationMethod.getController() despite controller being present:

java.lang.IllegalArgumentException: Cannot get string 'controller' from {type=JsonWebKey2020, id=did:key:zQ3shjmnWpSDEbYKpaFm4kTs9kXyqG6N2QwCYHNPP4yubqgJS#zQ3shjmnWpSDEbYKpaFm4kTs9kXyqG6N2QwCYHNPP4yubqgJS, controller=did:key:zQ3shjmnWpSDEbYKpaFm4kTs9kXyqG6N2QwCYHNPP4yubqgJS, publicKeyJwk={kty=EC, use=sig, crv=secp256k1, kid=vvDdKCl15we8gff3Oei7PbQoAoAAb_b9VVtK9uUDiuU, x=TEIJN9vnTq1EXMkqzo7yN_867-foKc2pREv45Fw_QA8, y=9yiymlzdxKCiRbYq7p-ArRB-C1ytjHE-eb7RDTi6rVc, alg=ES256K}}
	at foundation.identity.jsonld.JsonLDUtils.jsonLdGetString(JsonLDUtils.java:162)
	at foundation.identity.did.VerificationMethod.getController(VerificationMethod.java:140)
	at web5.sdk.dids.DidKeyTest$ResolveTest.resolving a secp256k1 DID works(DidKeyTest.kt:63)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:686)
	at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
	at 

digging into the code a bit. it seems as if VerificationMethod requires a JSON-LD @context in order to access the controller property.

Is this intentional? I don't see context being a required property of a verification method in the DID spec.

Maybe i'm understanding incorrectly but, if context is required, i'm not sure how this library is expected to be used to build strongly typed DID documents for did methods that do not require verification methods to include @context

Some minor things that may help consumers:

• ParserException should become a RuntimeException. Maybe renamed to DidParseException.
• all except didReference should be transient?
• the class itself should be annotated with @JsonSerialize(using = ToStringSerializer.class) to be compatible with rest layer.
• equals method is broken return this.didReference.equals(obj); rather than something like return obj instanceof DID && (this.didReference.equals(((DID) obj).didReference));

HI @peacekeeper

I have some point to clear correct me if i am wrong

Create VC with proof using verifiable-credentials-java library
And create DID from the website which you given and add the DID while generating VC
By completing above steps can generate a proper VC that can verify or upload in third party wallet like dock ?? Is any steps missing ??

currently there are many different repositories:

• verifiable-credentials-java
• did-common-java
• universal-resolver-java
• http-did-auth-proxy
• did-auth-relying-party

some hosted here, other somewhere else. It would be great to see those (some) efforts merged into a single repository with a multi-project setup. This to:

• simplify playing around with the entire tool stack.
• add documentation spanning all those closely related project (e.g. with asciidoc).
• Maybe then also to publish the artifacts to jcenter.
• let people star it in one place... :-)
• aligned versioning to know what works together
• add a build system like travis to verify the components

if there is an interest, I can also help with that.

the DIDDocument.builder().capabilityDelegationVerificationMethod method actually adds the supplied verification method as a capabilityInvocation.

Is this intentional? if not, PR #21 fixes the issue. feel free to close PR if the way it currently works is intended