Conversation
26.md
Outdated
|
|
||
| ## Client Behavior | ||
|
|
||
| - Key fetch: Wallets fetch the OHTTP key configuration from `gateway_url + "/ohttp-keys"`. If `gateway_url` is not provided, wallets SHOULD fetch from the mint origin at `"/ohttp-keys"`. |
There was a problem hiding this comment.
RFC 9458 cites https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-key-consistency-01 as general reccomendations for key consistency, probably worth linking here.
A mechanism analogous to certificate transparency logs probably makes sense as a future extension, both for OHTTP keys and for the token public keys, I'm happy to share some ideas, and i'm also curious what strategies existing cashu clients use for token key consistency
There was a problem hiding this comment.
We use the keyset id. The wallet verified the keyset id is verified by the wallet before being used https://github.com/cashubtc/nuts/blob/main/02.md#deriving-the-keyset-id
26.md
Outdated
| ## Client Behavior | ||
|
|
||
| - Key fetch: Wallets fetch the OHTTP key configuration from `gateway_url + "/ohttp-keys"`. If `gateway_url` is not provided, wallets SHOULD fetch from the mint origin at `"/ohttp-keys"`. | ||
| - Encapsulation: Wallets construct a BHTTP request that mirrors a normal Cashu API call (method, scheme, authority, path, headers, and body), encapsulate it with the fetched key config, and send it to the OHTTP gateway endpoint at `"/.well-known/ohttp-gateway"` through a relay. |
There was a problem hiding this comment.
in BIP 77 we require padding the encapsulated BHTTP ciphertext to 8192 bytes to resist traffic analysis. Perhaps it makes sense to make a similar recommendation for cashu. If the two user bases share the same set of OHTTP relays and the OHTTP gateway does not reveal which protocol the client is using, it would be beneficial if this value was shared by both protocols.
3 participants
Uh oh!
There was an error while loading. Please reload this page.