ChainAgnostic
signature suite standardization issues?
There's been a bit of grumbling around DIF github repos [edit: and now on the re-charter repo of the VC WG] and slack lately about how to handle the recovery bit in ES256K-R - it seems it was never registered publicly? the COSE working group at IETF registered regular ES256K, but no one attempted to register it. Is there interest in the CASA community to do this, or is there interest to set up a grant through gitcoin or DIF or any other grant-managing org to outsource it? if so, we might want to sketch such a grant in pencil before amsterdam!
Registered where exactly?
The only place CAIPs use secp256k1 is for CACAO which relies on EIP191.
Err, sorry, I may have phrased that imprecisely.
IANA can register an algorithm name like ES256K-R once there is an RFC process begun (not completed) at IETF that the IANA registry can point to. There are perhaps other ways to get an algorithm registered, but Orie suggested the COSE WG at IETF because they already did ES256K and it would presumably go faster there, as so much production software is using the recovery-bit pattern that is so common in the ethereal lands.
and even if it's not worth anyone's time to see an IETF/IANA imprimatur on the normative specification of the ES256K-R PubK recovery, it might also be good to at least define it somewhere. have you seen it registered anywhere? it would be good to link from the DIF repo, if nothing else, to aid discovery for implementers of vc-jwt. either way...
maybe a CAIP defining pubK recovery use-cases/needs so that a corresponding section could be added to namespaces?
It would certainly help bring more blockchains into scope for cross-chain usecases (including did:pkh)...
For context, I think this question is motivating the query-- VC WG is rechartering for round 2, and it would help put VC-JWT interop in scope for VCWG2 if there were a canonical specification they could link to defining how secp256k1 issuers are dereferenced (and specifically, how public keys recovered from PKHs), e.g. for a VC-JWT with an issuer like did:ethr:0x123... (or, more pointedly, for did:pkh:eth:0x1234). which means picking and registering a URL to be "the ES256K-R spec" (a GH thread will probably not pass muster for VCWG2 purposes)
A friend did find this useful comment from Pieter Wiulle: https://bitcoin.stackexchange.com/questions/38351/ecdsa-v-r-s-what-is-v/38909#38909 It would be very helpful for specifying at least how BTC and Eth do it :D