signature suite standardization issues? about caips HOT 4 OPEN

Registered where exactly?

The only place CAIPs use secp256k1 is for CACAO which relies on EIP191.

from caips.

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)...

from caips.

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)

from caips.

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

from caips.