-
Notifications
You must be signed in to change notification settings - Fork 129
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
add did:jwk method support #1128
add did:jwk method support #1128
Conversation
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.
An excellent PR, thank you for contributing this!
I added some notes about error messages and a question about the spec.
Please take a look.
} | ||
if(keyType === 'Secp256r1') { | ||
const EC = new elliptic.ec('p256') | ||
// add '03' prefix to public key |
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.
Where is this prefix coming from?
Can you please share a link to some reference?
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.
We do it in our implementation as well (compressed format):
https://github.com/Sphereon-Opensource/ssi-sdk/blob/develop/packages/jwk-did-provider/src/functions.ts#L113
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.
It is added to indicate a compressed public key, otherwise we have an invalid hex string. The prefix (02 if the y
coordinate of the public key point is even, 03 if the y
is odd) is removed in the Veramo kms: https://github.com/uport-project/veramo/blob/abfba31ff8497f00cddec5ca7a561fe32b1ab0bb/packages/kms-local/src/key-management-system.ts#L333
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.. this seems odd (no pun intended :) )
Veramo kms should not remove this prefix. At most, it should remove the 0x
prefix from hex encoded public keys, but not the parity.
If it's removing the parity it is a bug.
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, it really is removing the parity (https://github.com/uport-project/veramo/blob/9c73d98fd217ed9a612767f49a235cdbf43619cb/packages/kms-local/src/key-management-system.ts#L333).
@nklomp I missed this in my original review. Can you share some insight for why this would be needed?
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.
It shouldn't. I think we might need to look at how to fix it for any keys already stored though
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 add a new script to the @veramo/data-store#migrations
, but it will only cover the TypeORM based storage.
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.. actually, it will have to be done manually because the TypeORM migrations don't have access to the decryption key to get the private keys and recompute the correct public key :(
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.
Yeah, I think we can do it in code as well. A simple check for the prefix on a Secp256r1 key should suffice
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.
assertionMethod: [`${did}#0`], | ||
authentication: [`${did}#0`], | ||
capabilityInvocation: [`${did}#0`], | ||
capabilityDelegation: [`${did}#0`], | ||
keyAgreement: [`${did}#0`], |
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.
According to the did:jwk spec, the key relationships should consider the use
property of a JWK.
- When
use
isenc
, only thekeyAgreement
relationship should be added. - When
use
issig
, all except thekeyAgreement
relationship should be added.
I'm not aware of other implementations of this resolver so I can't tell if imposing this alignment with the spec would cause incompatibilities. What do you think?
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 could have a look at our Veramo compatible did:jwk implementation:
https://github.com/Sphereon-Opensource/ssi-sdk/blob/develop/packages/jwk-did-provider/src/functions.ts#L70
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 have added the use
property to the resolved JWK object and the corresponding key relationships according to the spec.
Cool. We also created a JWK DID provider for Veramo, which looks very similar but has some small changes compared to this PR.
We created it in our repo, as we needed it as part of the JFF Plugfest. I think it makes sense that we merge some features. https://github.com/Sphereon-Opensource/ssi-sdk/blob/develop/packages/jwk-did-provider |
Co-authored-by: Mircea Nistor <mirceanis@gmail.com>
Co-authored-by: Mircea Nistor <mirceanis@gmail.com>
Co-authored-by: Mircea Nistor <mirceanis@gmail.com>
Co-authored-by: Mircea Nistor <mirceanis@gmail.com>
Co-authored-by: Mircea Nistor <mirceanis@gmail.com>
…essage Co-authored-by: Mircea Nistor <mirceanis@gmail.com>
…essage Co-authored-by: Mircea Nistor <mirceanis@gmail.com>
…essage Co-authored-by: Mircea Nistor <mirceanis@gmail.com>
…essage Co-authored-by: Mircea Nistor <mirceanis@gmail.com>
…essage Co-authored-by: Mircea Nistor <mirceanis@gmail.com>
…m/veramo into did-jwk-support
…id-jwk-support
@mirceanis thank you for your comments. I have updated the implementation according to your suggestions. The changes also contain support for better error handling for the did resolution and the ability to import supported keys. The implementation is a bit different than the one from Sphereon, but the functionalities are covered. @nklomp thank you very much for pointing that out. This PR should provide the basic functionalities for did:jwk method, improvements and changes to the implementation could be made in subsequent PR. If you have any other suggestions we are open to it. |
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 looks good!
I still have doubts about the prefix added to Secp256r1 public keys and I'll have to look into the key manager implementation to figure out where it's removing the parity.
Did you already spot this to speed up my search? nevermind, I found it.
} | ||
if(keyType === 'Secp256r1') { | ||
const EC = new elliptic.ec('p256') | ||
// add '03' prefix to public key |
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.. this seems odd (no pun intended :) )
Veramo kms should not remove this prefix. At most, it should remove the 0x
prefix from hex encoded public keys, but not the parity.
If it's removing the parity it is a bug.
Codecov ReportBase: 80.25% // Head: 85.17% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## next #1128 +/- ##
==========================================
+ Coverage 80.25% 85.17% +4.92%
==========================================
Files 118 149 +31
Lines 4056 15261 +11205
Branches 875 1612 +737
==========================================
+ Hits 3255 12999 +9744
- Misses 798 2262 +1464
+ Partials 3 0 -3
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
What is being changed
Added an implementation of 'AbstractIdentifierProvider' for the did:jwk method according to the specification.
The provider currently supports Secp256k1, Secp256r1, Ed25519, X25519 key types.
Add create did:jwk identifier tests
Passing
Add resolve did:jwk tests
Passing
Add tests creating a valid VC using the did:jwk method
Passing
Quality
Check all that apply:
pnpm i
,pnpm build
,pnpm test
,pnpm test:browser
locally.