-
Notifications
You must be signed in to change notification settings - Fork 57
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
Refactor @web5/dids
to support first class Key Management
#393
Conversation
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
…or dids Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
Signed-off-by: Frank Hinek <[email protected]>
const did = await DidDht.fromPublicKeys({ keyManager, options, ...keySet }); | ||
|
||
// By default, publish the DID document to a DHT operations endpoint unless explicitly disabled. | ||
did.metadata.published = options.publish ?? true |
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.
what happens when someone is on a plane and we try to publish?
timeout exception?
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.
As currently implemented, if the gateway/relay cannot be reached when attempting to publish an exception will be raised.
One option is to pass publish: false
so that publishing isn't attempting (when calling create()
or fromKeys()
)... but that assumes the application is able to detect a lack of network connectivity and adapt.
One of the downsides to the current approach is that if a DID is being created for the first time (calling create()
to generate keys) and an exception is thrown during publishing, the newly generated keys aren't returned to the caller. By the time the exception is raised, the keys will have already been created and stored in the KeyManager
store so they end up "orphaned" since the function raises an error before it can return the DID object.
I went back and forth on this when initially implementing, but another approach is to catch any errors that occur during publishing and return did.metadata.published: false
. This way, the caller can detect and attempt to re-publish if they wish... and at least they have the DID URI and key references.
What are your thoughts?
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 that sounds reasonable.
I can't think of where it will be a huge deal for 'orphaned' keys will mess much up, they can just delete and make a new one.
Also you give them a lot of outs, setting publish to false.
If it turns into a big deal they can publish again later right?
I think leaving it the way it is is fine
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.
Its a great point and the more I think about it... the more I think we ought to look at a results object for DID registration (create
, update
, and deactivate
operations).
I'll leave it out for now and start a design doc to propose an approach.
Early thought is something that looks like: https://github.com/decentralized-identity/did-registration/blob/main/spec/spec.md#didregistrationmetadata
Signed-off-by: Frank Hinek <[email protected]>
Co-authored-by: nitro-neal <[email protected]>
|
||
// Replace ":" with "/" in the identifier and prepend "https://" to obtain the fully qualified | ||
// domain name and optional path. | ||
let baseUrl = `https://${parsedDid.id.replace(/:/g, '/')}`; |
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.
Would be nice to use http:// if the uri is localhost, for local dev purposes
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.
@ianpatton Interesting point to consider. The did:web
spec is fairly clear about requiring HTTPS. However, perhaps we could do something like a custom resolution option that allows for use of localhost endpoints that aren't secure.
Signed-off-by: Frank Hinek <[email protected]>
packages/dids/tests/fixtures/test-vectors/did-resolver/resolve.json
Outdated
Show resolved
Hide resolved
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.
Wow great job @frankhinek ! 🥇
I look forward to using this, I think it makes a lot of sense. Lots of new code and hard work.
Signed-off-by: Frank Hinek <[email protected]>
* Update Web5 Test Vectors to latest * Fix issue with c8 not reporting code coverage and bump version * Remove unnecessary option in crypto tsconfig and enable strict mode for dids * Add JWK Set to crypto package * Add did:jwk and did:web implementations * Add utility type to @web5/common * Improve DID Utility functions * Add FixedLengthArray utility type * Add support for Base32Z to Convert utility * Improve JWK type * Add InferKeyGeneratorAlgorithm utility type * Remove did-resolver dependency * Temporarily disable old implementations * Update DID JWK and DHT implementations * Rename createFromKeys to fromKeys and change default publishing behavior * Update JWK and DHT implementations * Rename DidKeySet to PortableDid and add uri * Reorganize tests and reintroduce DidResolver * Update package-lock.json * Rename P256 to Secp256r1 and add minimal tests * Add docs for undocumented methods * Finish reintroducing DID resolvers * Support secp256k1 as an algorithm identifier for generateKey() * Improve support for secp256r1 * Rename to LocalKeyManager & AwsKeyManager and improve docs * Fix Ed25519.validatePublicKey method signature * Refactor of DID Key * Complete implementation of DID Key * Add KeyCompressor type to @web5/crypto * Complete refactor of DidIon * Complete adding secp256r1 test vectors * Remove old dependencies and bump versions * Resolve package dependency issue * Remove old test-vectors directory * Remove references to tags in the XChaCha20Poly1305 comments * Remove duplication from DidDhtUtils.identifierToIdentityKey() * Correct typo in comments * Update crypto README * Correct typo, add DHT test, and remove unused file --------- Signed-off-by: Frank Hinek <[email protected]> Co-authored-by: nitro-neal <[email protected]>
* Update Web5 Test Vectors to latest * Fix issue with c8 not reporting code coverage and bump version * Remove unnecessary option in crypto tsconfig and enable strict mode for dids * Add JWK Set to crypto package * Add did:jwk and did:web implementations * Add utility type to @web5/common * Improve DID Utility functions * Add FixedLengthArray utility type * Add support for Base32Z to Convert utility * Improve JWK type * Add InferKeyGeneratorAlgorithm utility type * Remove did-resolver dependency * Temporarily disable old implementations * Update DID JWK and DHT implementations * Rename createFromKeys to fromKeys and change default publishing behavior * Update JWK and DHT implementations * Rename DidKeySet to PortableDid and add uri * Reorganize tests and reintroduce DidResolver * Update package-lock.json * Rename P256 to Secp256r1 and add minimal tests * Add docs for undocumented methods * Finish reintroducing DID resolvers * Support secp256k1 as an algorithm identifier for generateKey() * Improve support for secp256r1 * Rename to LocalKeyManager & AwsKeyManager and improve docs * Fix Ed25519.validatePublicKey method signature * Refactor of DID Key * Complete implementation of DID Key * Add KeyCompressor type to @web5/crypto * Complete refactor of DidIon * Complete adding secp256r1 test vectors * Remove old dependencies and bump versions * Resolve package dependency issue * Remove old test-vectors directory * Remove references to tags in the XChaCha20Poly1305 comments * Remove duplication from DidDhtUtils.identifierToIdentityKey() * Correct typo in comments * Update crypto README * Correct typo, add DHT test, and remove unused file --------- Signed-off-by: Frank Hinek <[email protected]> Co-authored-by: nitro-neal <[email protected]>
* Update Web5 Test Vectors to latest * Fix issue with c8 not reporting code coverage and bump version * Remove unnecessary option in crypto tsconfig and enable strict mode for dids * Add JWK Set to crypto package * Add did:jwk and did:web implementations * Add utility type to @web5/common * Improve DID Utility functions * Add FixedLengthArray utility type * Add support for Base32Z to Convert utility * Improve JWK type * Add InferKeyGeneratorAlgorithm utility type * Remove did-resolver dependency * Temporarily disable old implementations * Update DID JWK and DHT implementations * Rename createFromKeys to fromKeys and change default publishing behavior * Update JWK and DHT implementations * Rename DidKeySet to PortableDid and add uri * Reorganize tests and reintroduce DidResolver * Update package-lock.json * Rename P256 to Secp256r1 and add minimal tests * Add docs for undocumented methods * Finish reintroducing DID resolvers * Support secp256k1 as an algorithm identifier for generateKey() * Improve support for secp256r1 * Rename to LocalKeyManager & AwsKeyManager and improve docs * Fix Ed25519.validatePublicKey method signature * Refactor of DID Key * Complete implementation of DID Key * Add KeyCompressor type to @web5/crypto * Complete refactor of DidIon * Complete adding secp256r1 test vectors * Remove old dependencies and bump versions * Resolve package dependency issue * Remove old test-vectors directory * Remove references to tags in the XChaCha20Poly1305 comments * Remove duplication from DidDhtUtils.identifierToIdentityKey() * Correct typo in comments * Update crypto README * Correct typo, add DHT test, and remove unused file --------- Signed-off-by: Frank Hinek <[email protected]> Co-authored-by: nitro-neal <[email protected]>
Summary
The primary goal of this PR is to refactor the
@web5/dids
package to use the refactored@web5/crypto
package that substantively changed how key management was approached. In addition to making key management integral to the DID method implementations, it also changes the DID method API to include methods for instantiating DID objects from existing DIDs/keys. The same pattern is being implemented acrossweb5-js
,web5-kt
,web5-go
, etc.did:web
to@web5/dids
#263PortableDid
'sdid
property touri
#329@web5/dids
package to use@web5/[email protected]
#364did:jwk
to@web5/dids
#274did:dht
implementation based on spec changes #368