Keyset ID V2 #182
Keyset ID V2 #182
Conversation
| keyset_id_bytes = b"".join([p.serialize() for p in sorted_keys.values()]) | ||
| keyset_id_bytes += b"unit:sat" |
There was a problem hiding this comment.
I am wondering ... since we already depend for CBOR (for Token v4), maybe we can use CBOR here too instead of this custom serialization?
There was a problem hiding this comment.
What would the structure of the CBOR be?
|
Thank you! Please:
|
| def derive_keyset_id(keys: Dict[int, PublicKey]) -> str: | ||
| sorted_keys = dict(sorted(keys.items())) | ||
| keyset_id_bytes = b"".join([p.serialize() for p in sorted_keys.values()]) | ||
| keyset_id_bytes += b"unit:sat" |
There was a problem hiding this comment.
Once optimization could be to change b"unit:sat" -> b"u:sat" or even just b"sat".
(Edit: nevermind that, it will all be hashed in the end, so reducing the length of what's inside won't matter)
Might also be worth specifying the unit should be lowercased first.
There was a problem hiding this comment.
I don't think we have specified the units as case-insensitive yet. We should probably also do that if we include this change, right?
There was a problem hiding this comment.
Since the keyset ID commits to the unit, then it would make sense IMO.
If a client derives the keyset ID using a different capitalization, or if the mint changes the capitalization later on, the keyset ID would be invalid.
There was a problem hiding this comment.
@callebtc what do you think about units being case-insensitive and hashing the lowercase unit value?
| @@ -148,24 +172,24 @@ To receive the public keys of a specific keyset, a wallet can call the `GET /v1/ | |||
|
|
|||
| Request of `Alice`: | |||
|
|
|||
| We request the keys for the keyset `009a1f293253e41e`. | |||
| We request the keys for the keyset `01c9c20fb8b348b389e296227c6cc7a63f77354b7388c720dbba6218f720f9b785`. | |||
There was a problem hiding this comment.
What happens if a wallet that does not yet support V2 keysets makes a GET v1/keys/{8-byte-keyset-id} request?
There was a problem hiding this comment.
A request with a keyset ID prefix 00 should still be supported. A wallet that doesn't support keyset IDs with a prefix of 01 shouldn't get to where they are making this request since the keyset ID parsing will have already failed if the wallet is checking the version.
If a wallet doesn't check the version and sends a request for an 8-byte keyset ID from a token, we can consider having the mint resolve it for the wallet from the URL. But that feels like an optional requirement for the mint.
Does that address your question?
This PR introduces a new keyset ID version that commits to the keyset's unit and avoids keyset ambiguity between mints. Keyset IDs are now 33 bytes, with a one-byte version prefix before a 32-byte SHA256 hash.
Tokens maintain the same length by abbreviating the 33-byte keyset ID to the first 8 bytes: a one-byte version prefix before the first 7 bytes of the 32-byte SHA256 hash. While unlikely in practice, implementors should ensure that token keyset IDs are unambiguous to the mint when serializing.
Wallets will be responsible for expanding the abbreviated keyset ID to the full-length keyset ID.
It is now recommended to store the entire 33-byte keyset ID in a wallet's proof database.