diff --git a/proto/cmp/services/book/v1alpha/mint.proto b/proto/cmp/services/book/v1alpha/mint.proto new file mode 100644 index 0000000..c5fd485 --- /dev/null +++ b/proto/cmp/services/book/v1alpha/mint.proto @@ -0,0 +1,78 @@ +syntax = "proto3"; + +package cmp.services.book.v1alpha; + +import "cmp/types/v1alpha/common.proto"; +import "cmp/types/v1alpha/currency.proto"; +import "cmp/types/v1alpha/language.proto"; +import "cmp/types/v1alpha/payment.proto"; +import "cmp/types/v1alpha/pubkey.proto"; +import "cmp/types/v1alpha/traveller.proto"; +import "google/protobuf/timestamp.proto"; + +message MintRequest { + // Message header + cmp.types.v1alpha.Header header = 1; + + string validation_id = 2; + + string external_session_id = 3; + + cmp.types.v1alpha.Currency currency = 4; + + cmp.types.v1alpha.Language language = 5; + + string market = 6; + + string booking_reference = 7; + + repeated cmp.types.v1alpha.ExtensiveTraveller travellers = 8; + + string comment = 9; + + // Public keys that will be used to encrypt the private booking data + repeated cmp.types.v1alpha.PublicKey public_keys = 10; + + // Payment type, one of "on_chain", "off_chain_invoice", and "off_chain_vcc". + cmp.types.v1alpha.Payment payment = 11; +} + +message MintResponse { + // Message header + cmp.types.v1alpha.Header header = 1; + + // This must be a UUID according to RFC 4122 + string mint_id = 2; + + // This must be a UUID according to RFC 4122 + string validation_id = 3; + + string provider_booking_reference = 4; + + // FIXME: Is it enough to have an address? Normally NFTs have a contract address + // and a token id. + string digital_asset_address = 5; + + string transaction_id = 6; + + google.protobuf.Timestamp booking_timestamp = 7; + + MintStatus status = 8; + + // Transaction ID of the buy operation. This field is populated by the distributor + // (buyer) bot after the buy operation and passed to the distributor middlerware + // (partner plugin) in the mint response. + string buy_transaction_id = 9; +} + +enum MintStatus { + MINT_STATUS_UNSPECIFIED = 0; + MINT_STATUS_CONFIRMED = 1; + MINT_STATUS_FAILED = 2; +} + +// ![Diagram](https://storage.googleapis.com/docs-cmp-files/diagrams/proto/cmp/services/book/v1alpha/mint.proto.dot.xs.svg) +// [Open Message Diagram](https://storage.googleapis.com/docs-cmp-files/diagrams/proto/cmp/services/book/v1alpha/mint.proto.dot.svg) +service MintService { + rpc Mint(MintRequest) returns (MintResponse); +} diff --git a/proto/cmp/services/book/v1alpha/validate.proto b/proto/cmp/services/book/v1alpha/validate.proto new file mode 100644 index 0000000..7a54880 --- /dev/null +++ b/proto/cmp/services/book/v1alpha/validate.proto @@ -0,0 +1,66 @@ +syntax = "proto3"; + +package cmp.services.book.v1alpha; + +import "cmp/types/v1alpha/common.proto"; +import "cmp/types/v1alpha/price.proto"; + +message ValidationRequest { + // Message header + cmp.types.v1alpha.Header header = 1; + + // Search ID that is returned in the search response message in the `metadata`` + // (`SearchResponseMetadata`) field. + string search_id = 2; + + // Result ID that is that is returned by `result_id` field of the search result + // messages like `AccommodationSearchResult`. + // + // Because search requests may contain multiple queries, for example one room + // (unit) for 2 adults and one room for 2 adults and 1 kid and another room for 1 + // adult, here we are using a list of results IDs that the buyer wants to validate. + repeated int32 result_ids = 3; +} + +message ValidationResponse { + // Message header + cmp.types.v1alpha.Header header = 1; + + // Unique validation ID. This must be a UUID according to RFC 4122 + string validation_id = 2; + + // Status + ValidationStatus status = 3; + + // Validation objects + repeated ValidationObject validation_objects = 4; +} + +// Validation message that represents a single `result_id` from the search results +// message. +// +// TODO: Better name? +message ValidationObject { + int32 result_id = 1; + + cmp.types.v1alpha.PriceDetail price_detail = 2; + + // Validation key of the product. Example for flight key: + // "LH1154-BUSINESS-ZEUBUZP0-Z#LH1155-BUSINESS-CEUBUZP0-C" + string key = 3; + + // Status + ValidationStatus status = 4; +} + +enum ValidationStatus { + VALIDATION_STATUS_UNSPECIFIED = 0; + VALIDATION_STATUS_AVAILABLE = 1; + VALIDATION_STATUS_UNAVAILABLE = 2; +} + +// ![Diagram](https://storage.googleapis.com/docs-cmp-files/diagrams/proto/cmp/services/book/v1alpha/validate.proto.dot.xs.svg) +// [Open Message Diagram](https://storage.googleapis.com/docs-cmp-files/diagrams/proto/cmp/services/book/v1alpha/validate.proto.dot.svg) +service ValidationService { + rpc Validation(ValidationRequest) returns (ValidationResponse); +} diff --git a/proto/cmp/types/v1alpha/credit_card.proto b/proto/cmp/types/v1alpha/credit_card.proto new file mode 100644 index 0000000..afed2ce --- /dev/null +++ b/proto/cmp/types/v1alpha/credit_card.proto @@ -0,0 +1,12 @@ +syntax = "proto3"; + +package cmp.types.v1alpha; + +import "cmp/types/v1alpha/date.proto"; + +message CreditCard { + // FIXME: Can we use an int64 to represent a credit card number? + string number = 1; + Date expiration_date = 2; + int32 cvc = 3; +} diff --git a/proto/cmp/types/v1alpha/payment.proto b/proto/cmp/types/v1alpha/payment.proto new file mode 100644 index 0000000..219e462 --- /dev/null +++ b/proto/cmp/types/v1alpha/payment.proto @@ -0,0 +1,22 @@ +syntax = "proto3"; + +package cmp.types.v1alpha; + +import "cmp/types/v1alpha/credit_card.proto"; +import "google/protobuf/empty.proto"; + +// Payment message with one of field of types "on_chain", "off_chain_invoice", and +// "off_chain_vcc". +// +// "on_chain" and "off_chain_invoice" types are just `Empty` messages, setted only +// to specify the payment type as these do not require any additional info.enum +// +// "off_chain_vcc" is a `CreditCard` message type that contains virtual credit card +// number, expiration date and CVC. +message Payment { + oneof type { + google.protobuf.Empty on_chain = 1; + google.protobuf.Empty off_chain_invoice = 2; + CreditCard off_chain_vcc = 3; + } +} diff --git a/proto/cmp/types/v1alpha/pubkey.proto b/proto/cmp/types/v1alpha/pubkey.proto new file mode 100644 index 0000000..33a9fbc --- /dev/null +++ b/proto/cmp/types/v1alpha/pubkey.proto @@ -0,0 +1,7 @@ +syntax = "proto3"; + +package cmp.types.v1alpha; + +message PublicKey { + string key = 1; +} diff --git a/proto/cmp/types/v1alpha/traveller.proto b/proto/cmp/types/v1alpha/traveller.proto index 38b5420..d8c7ea3 100644 --- a/proto/cmp/types/v1alpha/traveller.proto +++ b/proto/cmp/types/v1alpha/traveller.proto @@ -10,7 +10,6 @@ import "cmp/types/v1alpha/document.proto"; // // ![Diagram](https://storage.googleapis.com/docs-cmp-files/diagrams/proto/cmp/types/v1alpha/traveller.proto.dot.xs.svg) // [Open Message Diagram](https://storage.googleapis.com/docs-cmp-files/diagrams/proto/cmp/types/v1alpha/traveller.proto.dot.svg) - message BasicTraveller { // Guest number, the lowest number is the lead-pax. This ID is also used for // referencing services linked to specific participants, like baggage. @@ -46,8 +45,11 @@ message ExtensiveTraveller { // referencing services linked to specific participants, like baggage. int32 traveller_id = 1; + // Traveller type from enum below + TravellerType type = 2; + // Gender from the enum below - GenderType gender = 2; + GenderType gender = 3; // Many systems might just have one field for all first names and just one field // for all surnames of a traveller. However, we see many countries with many @@ -62,8 +64,8 @@ message ExtensiveTraveller { // Conclusively systems that haye a limited number of first name and surname // fields can just use one antry and systems that have multipl can fit John legen // into first_name: John, first_name: Roger, surname: Stephens, surname: Legend. - repeated string first_names = 3; - repeated string surnames = 4; + repeated string first_names = 4; + repeated string surnames = 5; string phone_number = 6; string email = 7; repeated cmp.types.v1alpha.Document documents = 8;