]>

Germany contact@script4all.com

General Internet Engineering Task Force media purchasepurchaseexchangetransfer This document defines the purchase exchange format (PEF), which consists of signed purchase records, to enable sharing, verification, and transfer of information about license ownership. This enables sharing of abonnements, rentals, and one-time-purchases across platforms as well as deleting or switching accounts of (media) service providers without loosing or double-purchasing products. It can also be applied to non-media products.

Introduction The purchase exchange format (PEF) defines the format of signed purchase records, to enable sharing, verification, and transfer of information about license ownership. This enables to

• simplify and automate digital inheritance or (family) sharing across platforms,
• delete or switch accounts of (media) service providers without loosing purchases (also for data portability or correlation with EU Digital Markets Act),
• save (TV) recordings without storing the actual content,
• offer account-less services through modification, up- and download of purchase exchange formats,
• differentiate between levels e.g. an upgrade is needed for watching a purchased movie in cinema.

When purchasing media like videos, apps, or similar on different platforms, there may be overlapping purchases e.g. free content which is paid at a different streaming service, or subscriptions of different services with overlapping contents or rentals. By this you would pay multiple times for the same product. A signed list of purchases being exchanged between the service providers could avoid double-purchase of the same media items, by e.g. lowering the price of a subscription by the amount the media item would cost. Furthermore it may be a problem to change operating system platforms, if you would have to pay for apps in the new app store again, whereas you already have purchased the same products in the old one. A signed list of purchases being acknowledged by service providers could tackle this issue, whilst supporting fair competition.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in when, and only when, they appear in all capitals, as shown here.

Terminology Naming conventions throughout this document of attributes include use for offline or non-media purchases.

Product object

JSON object containing product data

Record

JSON object containing purchase information and a list of product objects

Signed Record

JSON Web Signature (JWS) containing a record as payload

Record Each record MUST be a JSON object for later conversion to a JWS payload (see ). The following properties/claims of a record are REQUIRED:

iss

issuer, as defined in

iat

timestamp of issuing for bookkeeping and maybe some legal requirements, as defined in

The following properties of a record are OPTIONAL:

jti

id e.g. to identify the transaction in the seller's bookkeeping, as defined in . For maintaining uniqueness across records in a simple way it is RECOMMENDED to use URL-style e.g. "seller.example/category/012345".

Timely Restrictions Timely restrictions are useful for rentals or subscriptions of products. The following properties of a purchase object are OPTIONAL:

nbf

timestamp from when the products are licensed for use, as defined in

exp

timestamp when the products' license will expire, as defined in

exi

seconds after which the record expires after first use / issuing, e.g. for time-flexible subscriptions or vouchers, as defined in

License Holder JWSs can be easily copied. Thus it is RECOMMENDED to include the license holder into the record. This is not mandatory to allow for anonymous use of this format. The following properties of a record are OPTIONAL and to be implemented as defined in :

• name
• given_name
• middle_name
• family_name
• birthdate
• locale
• address

It is NOT RECOMMENDED to use the address property/claim, as it may be difficult to re-acknowledge/re-issue a signed record after change of address. To enable features like family sharing across different service providers, only the property/claim "family_name" MAY be present.

Product Objects The REQUIRED property/claim "products" MUST have a JSON array (as defined in ) as value, containing product objects. Product objects are JSON objects (see ) with specific properties as defined in this section.

Identifier "id" Each product object MUST have the property "id". This is a string containing a unique url-style product identifier. For example "database.example/category/id" may be a valid id. Each id contains a prefix defining the product type concatenated with the actual value. Below you can find a list of RECOMMENDED identifiers for each type:

movie

Prefix: https://imdb.com/title/
Identifier: ID
Example: https://imdb.com/title/tt1254207

music

Prefix: isrc://
Identifier: uppercase
Example: isrc://AA6Q7-20-00047

or

Prefix: https://isni.org/isni/
Identifier: uppercase
Example: https://isni.org/isni/000000012146438X

book

Prefix: isbn://
Identifier: alphanumeric-only
Example: isbn://123456789X

app

Prefix: app://
Identifier: application identifier
Example: app://org.example.app

With this extendable identifier scheme you can …

• set up your own namespace e.g. if you invent and provide new products you can just use your website as prefix, and
• enable content creators to have product data stored with them and have others just referring to them, which reduces redundancy over the internet. Example would be a film studio creating movies while storing and updating title, licenses, etc. directly and automatically.

Additional Information It is RECOMMENDED, but for the sake of brevity not mandatory, to include helpful information as object properties. This might be necessary if the id prefix is not common, for still being able to identify a product e.g. a movie. If used, the following properties MUST be used with consistent naming:

title

product title e.g. movie title, song name

year

year of creation

creator

creator of product e.g. the film studio, song author

Other properties with the same meaning as one of the keys above MUST NOT use different key names. This means for example "song-name" is prohibited, because "title" is to be used instead.

Signed Record Above record doesn't provide data integrity. Thus the security of records depend on JSON Web Signatures (JWS) as their carrier. A signed record is a JWS with its payload being a representation of the record according to Step 2 of . Do not confuse the payload with the actual value of the "payload" property of a JWS. The more strict specification of a JSON Web Token is not used to allow for JSON representations of signed records. It is REQUIRED to use JWSs with asymmetric encryption keys, otherwise signatures couldn't be verified by others without giving up confidentiality of the signature key. Unsecured JWSs as defined in MUST NOT be used. To identify the JWSs as signed purchase records, it is RECOMMENDED to set the "typ"-claim to the Content-Type "TBD1" in its compact form as defined in .

File Format and Synchronisation JWSs and thus signed records are signed by only one entity, because a product is bought from only one seller (single person or group as a whole). To allow the exchange of multiple purchases bought from each a different seller, the file containing the purchases MUST be in JSON Lines format , and use appropriate file name suffixes (i.e. .jsonl or derivatives through e.g. compression like .json.gz). There MUST be zero or one signed records on each line. Synchronisation MAY be supported by product vendors or services through WebDAV file synchronisation . If this method is used, editors MUST take action against synchronisation issues e.g. synchronous writing of two different vendors. If necessary, the strategy for avoiding collisions MUST be the "merge" method i.e. keeping entries on doubt. It is highly RECOMMENDED to restrict file access to read-and-append-only without rewriting the file. Entries SHALL be terminated by other means than deletion e.g. by expiration timestamps, to allow:

• keeping a history of purchases,
• enable (immutable) streaming of the purchase exchange format line by line (see ) with empty lines as connection keep-alive,
• avoid file writing collisions by appending signed records without knowing the file content.

IANA Considerations

Media Type Registration IANA is asked to assign the media type "application/pef" in the "Media Types" registry in the manner described in , which can be used to identify a JWS as a signed record in purchase exchange format. The subtype name replaces the placeholder TBD1 as used in .

• Type name: application
• Subtype name: pef
• Required parameters: N/A
• Optional parameters: N/A
• Encoding considerations: 8bit; as JWS
• Security considerations: this document
• Interoperability considerations: N/A
• Published specification: this document
• Applications that use this media type: N/A
• Fragment identifier considerations: N/A
• Additional information:
  • Deprecated alias names for this type: N/A
  • Magic number(s): N/A
  • File extension(s): .jsonl, .ndjson
  • Macintosh file type codes: TEXT
• Person & email address to contact for further information: Maximilian Josef Frank, contact@script4all.com (REMOVE EMAIL BEFORE PUBLISHING)
• Intended usage: COMMON
• Restrictions on usage: N/A
• Author: Maximilian Josef Frank
• Change controller: Maximilian Josef Frank
• Provisional registration: no

Comment on "JSON Web Token Claims" Registry As the underlying format of signed records are JWSs instead of JWTs, there is no formal need to register the property/claim "products", containing a list of products for which to prove license-ownership (see ).

Security Considerations All the security considerations of JSON Web Signatures , also apply to this specification.

Authorization As signed records can be signed by anyone with custom keys, you MUST check its signature for authorization to issue purchases. For this a root storage of authorized certificates MAY be used in combination with a certificate chain and the "x5c"-claim of JWS as defined in . These certificates may be used to sign the public keys of the actual product sellers, whose signed keys are used to sign the actual purchase record.

License Holder If the license holder (see ) is encoded into the record, there may be issues with perfect authentication solely by the license holder information. Subjects with exactly same names and birthdates could use each other's licenses, if they also possess the signed record. As both possession of the signed record and knowledge of name and birthdate is required to abuse this circumstance, the risk is deemed to be low. Vendors MAY encode additional personal information into a record to strengthen authenticity, while maintaining portability and account-less use of the purchase exchange format.

Privacy Considerations This section uses terms from . It may be possible to create a fingerprint from the list of purchases and their properties (date, seller, etc.). This could be used to track/identify the user (individual) across services, but also over time on the same service - even though the user uses the service provider's service without an account. To mitigate this issue, …

• the file containing all signed records MAY be split into multiple files, so that only the relevant signed records are uploaded to the service provider, and
• signed records MAY be re-issued to modify the issuing date in regular intervals to reduce persistent attributes.

References Normative References IMDb.com, Inc. International ISBN Agency ISNI International Agency (ISNI-IA) Ltd. International ISRC Agency The OpenID Foundation Informative References

Example The following example represents a record for the purchase of the movie "Big Buck Bunny" at a fictional service provider called "Media Europe GmbH" on the 1st January 2022 at 00:00:00. The license to watch this movie is shared among the "Doe" family. The purchase is a rental from the time of purchase until the same day at 23:59:59 (inclusive). Please note that per definition the value of "exp" is the next second after the last valid second.

Example record