Orie Steele

Ideally, we would all agree to a concrete interface for LDKeyPair, which defined required members and methods... something like: https://github.com/transmute-industries/verifiable-data/blob/main/packages/ld-key-pair/src/types/KeyPair.ts We are basically trying to do this here: - https://github.com/transmute-industries/verifiable-data/tree/main/packages/bls12381-key-pair...

@vongohren yea... this is related to the relative refs, debate... see https://github.com/w3c-ccg/did-method-key/pull/36#issuecomment-855014917 TL;DR ... relative ref ids are terrible.... for exactly the reason you have indicated... we have similar code...

hmm, I hate this curve... I tend to try to align with: https://tools.ietf.org/html/rfc8812#section-3.1 ``` As a compressed point encoding representation is not defined for JWK elliptic curve points, the uncompressed...

@alexkravets thanks, can you provide example JSON / hex?

nvm :) was able to reproduce: ``` import * as keyUtils from '../keyUtils'; it('private keys are always 32 bytes', async () => { // this JWK generatetes 31 byte length...

@alexkravets this should be fixed in the latest unstable, but I will try and add your exact test case before closing this issue as resolved.

@alexkravets yes, my interpretation was that you wanted a consistent interface for both `verify` and `verifyDetached`. Are you saying you want: ``` verify(jws, publicKey) => Promise | thrown error. verifyDetached(jws,...

@alexkravets I would generally advise against `secp256k1` if you can avoid it... I think for verifyDetached a boolean makes sense, and for consistency with other JWT libraries, maybe `verify(jws)` should...

hmm, probably an issue with peerDependencies... please open a separate issue.

https://github.com/transmute-industries/verifiable-data/tree/main/packages/secp256k1-key-pair ^ we're planning on making all the did key libraries in this repo small wrappers around these "LDKeyPair" classes in our mono repo... We tend to think of did:key...