Public key prefix

[kimdhamilton]

Per this discussion, the "ecdsa-koblitz-pubkey:" prefix, originally used with Bitcoin addresses in the json-ld signature suite (Koblitz), is misleading because the address is in fact a hash.

In the LD signature suite, the "ecdsa-koblitz-pubkey:" prefix will likely be used to mean the actual public key (before hashing).

I propose deferring introducing to Blockcerts any changes related to this. That's because:

• if using a Bitcoin address, it's not yet decided what the new address prefix should be
• if using a public key, derivation of this requires non-trivial updates to the Blockcerts wallets providing this key
• It's not yet clear whether there is a strong advantage to using the public key (for Blockcerts scenarios)

I prefer waiting to get more information so we can make the right decision, and avoid introducing more complexity. We can address any updates in post-v2 Blockcerts versions; i.e. Blockcerts parsers will always interpret v2 as Bitcoin addresses.

Some options have included:

• ecdsa-koblitz-pubkey-hash-base58check:: long, but exact

• bitcoin:: more reader-friendly, but less precise. And introduces a pivot from key description to cryptocurrency description. Note other cryptocurrencies support this encoding...

• W3C Credentials CG thread

• SLIP standards

[fabcom-aaron]

Curious if the v2 Blockcerts schema is still OpenBadges compliant because I am running into issues in validation of all 4 blockcerts extensions as well as validating the publicKey value that is in the issuer profile. All yeilding errors from the openbadges validator.