package briolette.clerk

Get desktop application:
View/edit binary Protocol Buffers messages

• rpc AddEpoch (EpochUpdate, AddEpochReply)

  clerk.proto:48

  API for passing in a new, signed EpochUpdate

  message AddEpochReply

  clerk.proto:108

  (message has no fields)

• rpc GetEpoch (EpochRequest, EpochReply)

  clerk.proto:23

  TODO: allow non-ticket calls to get the current epoch and state updates. TODO: Move Epoch to an epoch server.

  TODO: Add RefreshTicket(RefreshTicketRequest) returns (RefreshTicketReply); For a given ticket, request a fresh ticket over the same credential. In general, credentials should be used for a single transaction. However, in the case of delegation of payment to a webserver or point-of-sale unit, a stable credential is desirable. Additionally, for p2p it can be desirable to exchange a payment "address" once with a peer and not need to replace it after every transaction. Refreshing a ticket enables this, but also allows any observers of the coins to discover if they have passed through a "public" credential, so there is a privacy tradeoff. Some p2p wallet implementors may choose share unique tickets per peer which they only refresh if a payment is received (which means sending funds to expired tickets IS valid). For merchants, these tickets may have an additional Tag which includes their tax-id or other authenticity data. Note, this means that tickets are not completely encoded in the Coin provenance, but instead only the credential is. The ticket must accompany the coin as necessary verifiable policy data, but its verification is simpler (ECDSA verify) and this enables refresh. v1 and other schemes may simplify this process as well as enable signature aggregation or other efficiency schemes. This call issues a fresh ticket for the given expired tickets if their signing NAC is not revoked and the credentials have not been involved in any double spends. rpc RefreshTicket(RefreshTicketRequest) returns (RefreshTicketReply);

  message EpochRequest

  clerk.proto:51

  • Version version = 1

  • uint64 known_epoch = 2

    Last seen epoch

  message EpochReply

  clerk.proto:56

  • optional EpochUpdate update = 1

• rpc GetTickets (GetTicketsRequest, GetTicketsReply)

  clerk.proto:46

  Returns time-bound tickets for receiving payments.

  message GetTicketsRequest

  clerk.proto:129

  TODO: Ensure there is a max message size since repeated fields can... go on.

  • Version version = 1

  • uint64 known_epoch = 2

    Last seen epoch

  • bytes nac_public_key = 3

    NAC public key to simplify lookup and hw mapping for all signed requests.

  • bytes ttc_public_key = 4

    The Ticket Transfer Group Public Key the ticket credentials are from.

  • optional TicketRequests requests = 5

  • bytes nac_signature = 6

    Version 0 just uses a NAC signature with the basename of the current epoch Over serialized requests. TODO: if we sign with the credential to get a ticket, then it still doesn't guarantee the NAC is on the TTC. This disparity allows for tunneled abuse. However, it seems wise to make the enforcement of TTC<>NAC binding to be done by the hardware vendors and the registrars. Then for the rest of the we should be able to assume that the binding is valid. If two devices are compromised from two different vendors, then one could tunnel ticket requests behind the other NAC causing the revocation of one class of devices, but not both. However, the tickets will still be basename-bound (in v0) to the actual device, but a quarantine of the other NAC group won't force it to identify itself. It can then proceed as a normal device performing legitimate transactions until a NAC compromise can be found in another device to shield its double spending. This is the main drawback of the NAC/TTC split. With v1, the double spending will expose the underlying device identity regardless which will make this attack irrelevant. So for now, we do not bother requiring a PoP for the credentials and assume NAC/TTC binding is enforced at registration. bytes ttc_signature = 3;

  message GetTicketsReply

  clerk.proto:158

  • repeated token.SignedTicket tickets = 1

  • bytes signing_key = 2

    Public key for verifying the tickets.

TODO: figure out delta updates, if needed.

Used in: EpochUpdate, receiver.InitiateReply, receiver.InitiateRequest

• uint64 epoch = 1

  utc time in 24 hours, or 86400 second, increments. For v0, the length of the epoch determines linkability across ticket requests.

• bytes group_bitfield = 2

  Each bit represents a valid group. If the bit is 1, it has been revoked. Group stay revoked until all references to the group have expired. At that point, a group may move back in to circulation. TODO: Explore unique id revocations.

• bytes extended_epoch_data_hash = 3

  For now, SHA256 of serialized ExtendedEpochData.

Used as request type in: Clerk.AddEpoch

Used as field type in: EpochReply, receiver.GossipReply, receiver.GossipRequest

• Version version = 1

• optional EpochData data = 2

• optional ExtendedEpochData extended_data = 3

• bytes epoch_signature = 4

  Signature over EpochData

• bytes signing_key = 5

  TODO: Factor out and use ECDSA recovery.

Used in: EpochUpdate

• repeated bytes ttc_group_public_keys = 1

  Lists the current set of supported token transfer credential group public keys. This does not necessarily change upon revocation. Even if a member private key (v0) is compromised, it will be unable to collect tickets as it will need to prove it isn't the abusive device or go through re-issuance to get a new network access credential. However, there are reasons to move wallets to new group keys, and this enables it. Simulation and active data collection will be required to understand how long effective propagation for a given deployment will take.

• repeated bytes epoch_signing_keys = 2

  Enable key rotation on epoch signatures.

• repeated bytes ticket_signing_keys = 3

  Enable key rotation on ticket signatures.

• repeated bytes mint_signing_keys = 4

  Enable management of trusted mints.

• uint64 epoch_seconds = 5

  Indicate how long the next epoch will be.

• optional ServiceMap service_map = 6

  TODO: Add trust bundle updates so key revocations, etc are not terrible. TODO: Add epoch key distribution to the registrar. Add service URIs for failover, recovery registration, etc.

Used in: TicketRequests

• bytes credential = 1

  randomized credential for a Clerk-known TTC GPK

• uint32 group_number = 2

  The ticket server will track NAC GPK<>group_num+expiration. This will allow hardware-specific revocation if a ticket is caught in a double-spend. Then all still-valid groups with NAC's will be quarantined and new ticket requests will require the device to connect to its NAC registrar to issue a credential against a new NAC GPK by performing a basename (v0) linked signature over the double spend with the TTC _or_ by performing a NAC basename-linked signature for the ticket request. TODO: The ticket server could allow temporary exceptions by having the request signed with the bad basename, but that would not work indefinitely because it would make future ticket requests linkable or require a new unlinkable token system to prove the exception.

Used in: GetTicketsRequest

• repeated TicketRequest request = 1