On-chain consent: API-in-Market or Service-in-Market

[oberstet]

A seller delegate may offer an instance of a service that provides data, conforming to an API (which is available in a given market).

Eg seller 7 registered in a market 3 may announce that one of its (seller 7) seller delegates is providing a service that implements API 6.

This announcment is a willing commitment of seller 7 to provide the respective data - in other words, seller 7 gives his consent to that.

We need to track this consent on-chain in a SC.

[oberstet]

Given a published API 4b740947-31d5-4a10-b7ce-4149bbc9ee1e with schema

/// Define an interface for accelerometer storage services.
rpc_service AccelStorage (type: "interface",
                          uuid: "4b740947-31d5-4a10-b7ce-4149bbc9ee1e")
{
    //
    // Examples of basic WAMP RPC and PubSub interface declarations
    //

    /// Procedure to store a series of samples. The time range of
    /// samples stored is returned.
    store (AccelSeries): TimeRange (type: "procedure", raises: "AccelSeriesRejected");

    /// Procedure that returns the last series of samples stored
    // within the given time range.
    get_last (TimeRange): AccelSeries (type: "procedure", raises: "NoSuchSeries");

    /// Event fired when a sample batch was stored. The time range
    /// of the stored samples is provided as event payload.
    on_store (TimeRange): Void (type: "topic");
}

and a registered XBR member "Alice" that has joined a XBR data market 7 as a seller, "Alice" may now announce that she will provide a service in that market implementing the given API by calling:

function offerService (bytes16 marketId,
                       bytes16 api,
                       string memory prefix,
                       address delegate) public;

• by Alice calling offerService, she (personally) agrees to (in conformance to GDPR) that she is fine with sharing her data according to ..
• schema defined (technically)
• api terms - if any (legally)
• market terms attached to the market (legally)
• xbr network terms to which every xbr network member agrees (legally)

---

further, she

• specifies her seller delegate that will produce and share/sell the data according to the API
• the WAMP URI prefix under which the delegate will (technically, at the WAMP level) implement the API

[oberstet]

here is an example of the data association we need to track:

Market Actor	Market	APIs provided	APIs consumed	Comments
Alice	Market 7	API 3, API 5		Alice is a pure seller in market 7
Alice	Market 5	API 3	API 7, API 9
Alice	Market 3		API 10, API 11, API 12
Bob	Market 7		API 3, API 5	Bob is a pure buyer in market 7
Fred	Market 7	API 3	API 5	Fred is both a buyer and seller in market 7
Joe	Market 7	API 3	API 3	Joe is both a buyer and seller (of same API) in market 7

[oberstet]

for the discussed variant, which is actually "API-in-Market", pls see https://github.com/crossbario/xbr-protocol/blob/master/docs/_static/docs/xbr_datamodel_variant1.pdf

This will result in eg:

Consent matrix for XBR Member „Alice“
	Market 1	Market 2	Market 3
consume API 1	x		x
consume API 2	x	x
consume API 3		x	x
provide API 1	x	x	x
provide API 2		x	x
provide API 3		x
An „x“ means: the member gave consent to consume/provide data under the respective API and in the respective Market. Any service instance (delegate) run by or for the member that implements (at least one of) the consented APIs will be allowed to do so (provide/consume data under the API).

---

the main variant would be: "Service-in-Market" consent tracking https://github.com/crossbario/xbr-protocol/blob/master/docs/_static/docs/xbr_datamodel_variant1b.pdf

[oberstet]

XBRMarket.setOptIn(api_id [uint128], consume bool, produce bool);

[oberstet]

• this has now landed via PR first part of refactoring #90
• we have chosen the "service in market" level of tracking consent
• eg see https://xbr.network/docs/protocol/api/index.html#setconsent