copious-counters

copious-counters

Counting services for assets and users with unique ids.

This service does the following:

• manages registration of assets and their associated percentage contracts.

• manages regsitration of exposition services

• negotiates with exposition services the use of cipher keys in order to expose assets for use

• counts each use of the cipher tied to an asset and attributes payment to the asset creators as well as portions to exposition services

Definition: Exposition Service - a services that provides end users with a view of stored data.
Example: Streaming service, Blog service, Human Machine Interface.

Copious Counters is a TLS connected service.

Copious Counters does not store assets. It assumes that assets have a unique ID such as a SHA256 hash or a CID from IPFS.

APPLICATIONS

There are two service applications that can run optionally:

• Counter Web Service
• Counter Endpoint Services

Counter Web Service

This application has some of the same components as a mini-link server, which may be found in the copious-world github repositories. It provides basic searching for meta descripitions of data.

In the case of the counter service, searching is not open to browser clients (unless it is an admin application). Searching is provided for mapping media asset identifiers to actual media stored in repositories accessible by repository bridges (also within copious-world repositories).

The counter web server maintains a relationship between globally persistent publication services, media creators, media consumers, and streamers.

• Publishers send meta descriptions to the counter service.
• Media creators register their content via publishers and provide their payout contracts to the counting serivce
• Media consumers garner a media asset id from a mini-link searcher (or similar) and request the counter to find a streaming service and povide a link to the media stream
• Streaming services provide a link via the counter to media the streamer will decrypt and send to a consumer once it (streamind service) is assured that a count of the stream is made by the counter

The counter web server will check that the user is activily engage in a session and that the counter has a contract to a regitered creative.

Counter Oracle Interface

The counter web service does not by itself check on or maintain tables to consumers, creators, and contracts. Instead, it relies on other backend services to provide the information when it is requested.

• sessions - the counter web service will request that a consumer session number be mapped to a user with an existing and active wallet.
• creatives - the creators of content will be registered and their ids will map to on chain identities via chain oracles.
• contracts - these may be stored locall6 in part in JSON objects that map payee identities to accounts, where the accounts will be founnd on chain.

Code for an application (reference) is in this repository. The file, index.js, contains the entry to the service. The main client to the service will be the web service application.

Business Processes

Asset Registration

Asset registration begins within a client program such as a web brower or a desktop app. Asset registration requires the exchange of keys and the identity of assets and creatives (those who make the asset). A creative may make the asset or an agent may use a client program on behalf of the creatives.

It is up to the client program to encrypt the asset. It is assumed that the client will use AES encryption. The AES key used to encrypt the asset must be generated by the client program. Registration provdes a means for allowing the Copious Counter service to obtain the key so that it may be shared with registered exposition services.

Asset Registration Process Steps

1) Start Registration

client initiates

The registration process begins by the client programming identifying itself to the Copious Counter by connecting over TLS and sending an unique ID of the creatives (e.g. an IPFS CID for a list of contributors to the asset). { 'command': 'register' }

response

The Copious Counter responds by sending a public wrapper key for use by the client. The client program uses the key to wrap the AES key use to encrypt (encipher) the asset.

2) Send Wrapped Key and Unique Asset ID

client

The client encrypts the data and obtains a unique ID UID for the encrypted form of the data. (In the case of IPFS, this will be a CID obtained from adding the encrypted data to IPFS.) The client will then wrap the AES key with the public wrapped key it received in the first step. Following that, the client will then send a command object that contains the wrapped AES key, the return of the public wrapper key, and the UID of the asset. { 'command': 'store_key' }

note: the wrapped key is returned in order to identify the transaction

response

The Copious Counter will return the UID of the creatives associated with the asset. (In the case of IPFS, this will be a CID.) Optionally, the Copious Counter may send a public verification key for use against signatures sent in later steps.

3) Verification (final registration step)

client

Upon receipt of the creatives' UID, the client will respond with the public wrapper key sent in step 1. The Copious Counter service will finalize the registration, making sure that its data tables are rectified. Optinally, the client may send a { 'command': 'verify_key' }

response

The Copious Counter will return the wrapped AES key, which was sent in step 2. Optionally, the signatured of the key may be returned, and the client may verify the signature against its copy of the wrapped AES key.

Exposition Service Registration

An exposition service requiring the use of assets stored in repositories by creatives, will need to obtain keys to decipher the assets so that they may exposed to viewers. These exposition services should form a relationship of trust with a counting service and should supply their own public wrapper keys in order to obtain ciphers keys use in unlocking assets.

An exposition service should obtain an publically verifiable unique ID in order to introduce itself to a counting service. And, it should provide the counting service with a public wrapper key to keep on file for later cipher key requests.

Exposition services requesting keys from a counting service without introduction should fail to obtain cipher keys for assets. Exposition services will have to be trusted not to give out keys they obtain. However, a process of key expiration and refresh will have to be considered in order to reign in possible piracy. Other processes may also be considered. For instance, each registered exposition service may have its own enciphered copy of an asset. Also, an exposition service will have an incentive to ask for a count of a play since it will not be paid by the counting service otherwise. A pirate exposition service would be one that obtains a clear copy of an asset and charges consumers for exposition without requesting a count from anyone, thereby bipassing payment to creatives.

Exposition Service Registration Process Steps

1) Start Registration

client initiates

The exposition service idenitifies itself with a publicly verifiable UID (a CID in the case of IPFS) and provides a public wrapper key at the same time.

The counting service should be able to use the UID to obtain information about the exposition service and to establish payment processes. If the exposition service can be verified, the counting service will store the UID with the public wrapper key which it will use at a later time to send AES keys for unlocking assets to be exposed to viewers. { 'command': 'exposition_service' }

response

The Copious Counter service will provide a signature of a hash of the the following: the exposition service public wrapper key concatenated with the exposition UID. The reponse will also include a public verification key.

Asset Key Retrieval

When an exposition service wishes to expose an asset to viewers, it will need to retrieve the AES key for that asset.

The exposition service must identify itself to the counting serivce and identify the asset as well.

Key Retrieval Process Steps

1) Request

exposition client

The exposition service sends a request object containing the UID (CID in the case of IPFS) of the asset and the UID (CID in the case of IPFS) of the exposition serivce. Included in the request object are UIDs of the consumer and the service providing a link to the asset. The consumer is idenitified as the source of funds for a single exposition.

Using the UIDs, the counting service accesses the AES key used to encipher the asset along with the public wrapper key of the exposition service. The counting service counts the plays of the asset as a whole and counts the plays along the consumption path, consumer, linker, exposer. The counting service may determine if there are funds for the exposition at the time of the request or may attempt to rectify funds later.

reponse

The Copious Counter service responds with the wrapped AES key, wrapped by the public wrapper key belonging to the exposition service.

Asset Key Update

From time to time, one or more encrypted copies of the asset should be rekeyed; that is, they should be deciphered with an old key and enciphered with a new key. When this process takes place, all replicas of a counting service (peers) and creatives should be notified that the keys have been changed.

This process may be requested by someone who adminsters a counting service. But, it may be configured to take place as the result of various triggers. One trigger may be, simply, the amount of time a key has been in use. Other triggers may arise if the counting service can ascertain that piracy has occured.

When this process involves an administator, it shall be initiated by command line processes. Peers are expected to have subscribed to an update topic for this operation. And, other clients, such as creatives may receive an email message aprising them of the change.

Configuration

Encryption Parameters