Backend spec #2
Backend spec #2
Conversation
|
I've been sitting on this for a few days, and it will likely need more specifics put in, but this is meant to be as general as possible to allow for alternate implementations |
npmaile
requested review from
ahinchliff,
dviator and
italianst4
and removed request for
ahinchliff and
dviator
|
|
||
| **alice** A fictional phonon user generally wishing to receive phonons from bob | ||
|
|
||
| **phonon transfer packet** the encrypted data containing a number of phonons while in transit between phonon sce units |
There was a problem hiding this comment.
I suppose that for purposes of this document I'd rather add a little extra to distinguish between a phonon in-transit and a phonon at rest. I think I'll leave it the way it is, and when we get more to polishing it, I'll add an (in transit) to the ones not currently held in a card.
| all phonon interactions must adhere to the following Constraints | ||
| 1. A phonon's private key may not be accessible by more than a single entity at one time | ||
| 1. A phonon's private key MUST remain secret unless the phonon is destroyed at or before the time of the phonon being viewable by an outside system or entity | ||
| 1. A phonon private key may not be transferred to a phonon sce that has not been verified by the sending phonon sce |
There was a problem hiding this comment.
This is arbitrary restriction that makes little sense. It is essentially equal to sending to a "verified" card and the receiver either redeeming the phonon (key will be known) or throwing the card away (key is lost). The recommendation here is that a client SHOULD verify the receiver (possibly against a blacklist/reputation list etc)
There was a problem hiding this comment.
i disagree. phonons cant be sent to non-phonon hardware, and must be verifies prior to sending. that said, if we allow unverified sending, then redeeming a phonon is as simple as encrypting the private keys to an unverified key owned by the client computer, and removes a little complexity around redemption and deletion...
There was a problem hiding this comment.
Verified by a client - yes. Verified by the card - not sure.
Redeeming via encryption against user-specified key would be very beneficial (if I kept my keys in some other system, capable of receiving them "securely")
There was a problem hiding this comment.
yea I think I agree that this is not a card level restriction. I think the constraint is actually the other way around?
- A phonon sce must only receive phonons from valid phonon sce's.
| ### Encoding | ||
| For the purposes of this document, any data being described will be in JSON format. | ||
| Data sent between the terminal and the phonon sce will be implementation dependent. | ||
| Phonon transfer packets must be encoded in [CBOR](https://www.rfc-editor.org/rfc/rfc8949.html) format |
There was a problem hiding this comment.
So we're proposing to switch from APDU to CBOR?
There was a problem hiding this comment.
HTTP is messages, and it works over TCP, but also over HTTPS, which itself can be implemented over TCP or UDP. So the change is from "custom TCP" to "messages with HTTP semantics". The important change from client coding perspective is that there are layers and functions:
"sendMessage(message)" -> cborify() -> (optional secure_channel_wrap()) -> apduify() -> card with its archaic ISO 7816-4 APDU interfaces
card with its archaic ISO 7816-4 APDU interfaces -> parse_apdy() -> unwrap_secure_channel() -> decborify() -> "onRespons(response)"
The point here being that constructing APDU-s "by hand" in the form of CLA/INS/P1/P1 with TLV payloads is gone. Compare: https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#nfc-framing
There was a problem hiding this comment.
So we're proposing to switch from APDU to CBOR?
we are switching from tlv to cbor (at least for transfer packets)
There was a problem hiding this comment.
@maevyn11 let me know if you need more explanation or if you have an issue with making this change so I can close this comment thread
| ```json | ||
| {"pubkey":"binary data"} | ||
| ``` | ||
| ## SET_DESCRIPTOR |
There was a problem hiding this comment.
| ## SET_DESCRIPTOR | |
| ## SET_METADATA |
No description provided.