]> Purchase Exchange Format (PEF)
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 subscriptions, 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 items and physical objects like family-shared rentals of tools or proof of purchase for guarantee claims.
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 (see ),
  • delete or switch accounts of (media) service providers without loosing purchases (also for data portability or correlation with EU Digital Markets Act),
  • save television recordings or similar without storing the actual content,
  • offer account-less services through modification, up- and download of records in purchase exchange format,
  • 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 items in the old one. A signed list of purchases being acknowledged by service providers could tackle this issue, whilst supporting fair competition. The purchase doesn't need to be about digital media. It can also be about physical objects (like a tool). By this both family sharing of rentals and simplification of guarantee claims are enabled. You can find an example in . With the purchase of a physical object mostly also comes a bill, which would prove ownership for e.g. guarantee claims. However this application is subject to local jurisdiction. Therefore this document focuses on digital items.
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, see
Record
JSON object containing purchase information and a list of product objects, see
Signed Record
JSON Web Signature (JWS) in JSON Serialisation format () containing a record as payload, see
License
License in sense of this document means any grant to use a service. This can also be an implicit license to use a tool for a limited time (i.e. a rental of the tool). See for examples on physical objects.
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 . As the format in this document is for exchanging information, this field must be in string representation of Distinguished Names format (e.g. "CN=Example Company"). For further examples have a look at the appendix .
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 accessible URIs e.g. "https://seller.example/category/012345".
Timely Restrictions Timely restrictions are useful for rentals or subscriptions of items. The following properties of a purchase object are OPTIONAL:
nbf
timestamp from when the items are licensed for use, as defined in
exp
timestamp when the items' license will expire, as defined in
exi
seconds after which the record expires after first use or 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. For enabling anonymous usage of this format, this is not mandatory. 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" and "locale" MAY be present. See for an example. This list of license holder properties is not exhaustive, so you can add your own properties. Nevertheless all properties MUST be compatible with . An example is given in . Please be aware of the privacy considerations in for identifying data.
Product Objects The REQUIRED property/claim "items" 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. For signing multiple product objects in a single signed record see .
Identifier "id" Each product object MUST have the property "id". This is a string containing a unique URI-style product identifier (see ). For example "https://database.example/category/1234" may be a valid id. Each id contains a prefix defining the product type (e.g. https://database.example/category/") concatenated with the actual value (e.g. "1234"). Every identifier MUST be accessible. That means any used URI scheme must be registered according to and the URI resource MUST be accessible via the URI. For example if the identifier is "https://example.com/movie/123", then this url MUST be accessible via a browser revealing further information about the product, leading to a page for purchasing the product, or similar. 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: https://isrcsearch.ifpi.org/#!/search?tab=lookup&isrcCode=
Identifier: uppercase , only alphanumeric characters
Example: https://isrcsearch.ifpi.org/#!/search?tab=lookup&isrcCode=AA6Q72000047

or

Prefix: https://isni.org/isni/
Identifier: uppercase
Example: https://isni.org/isni/000000012146438X
book
Prefix: https://isbndb.com/book/
Identifier: alphanumeric-only
Example: https://isbndb.com/book/123456789X
app (F-Droid app store)
Prefix: https://f-droid.org/packages/
Identifier: application identifier
Example: https://f-droid.org/packages/org.unifiedpush.example
physical product
Prefix: https://barcodelookup.com/
Identifier: (former EAN)
Example: https://barcodelookup.com/0123456789005
Some items may have multiple identifiers e.g. an application being present in multiple app stores. To tackle issues with cross platform acknowledgement of licenses you SHOULD include additional information e.g. title (see ), and use official databases where available. With the above extendable identifier scheme you can …
  • set up your own namespace by using your website as prefix e.g. "https://example-shop.com/" (see for physical objects), and
  • enable content creators to have product data stored on their own servers and have others just referring to them. An example would be a film studio creating movies while storing and updating title, licenses, or similar on its own servers. An external streaming service now can refer to this data and automatically receives updates (e.g. movie version, name in different languages, …). This reduces redundancy.
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 or 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. To allow for JSON representations of signed records the more strict specification of a JSON Web Token is not used. 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" (without quotation marks) 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, there may be different formats of exchanging multiple signed records.
File A file containing the signed records 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. See for an example. Synchronisation MAY be supported by product vendors or services through WebDAV file synchronisation . In this case license holders SHOULD be able to specify their own storage location, e.g. ones own cloud storage. 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 from both vendors on collision. 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.
Client Certificate Another option would be to use the existing X.509 client certificate authentication mechanism, where a website or service provider requests a certificate containing the signed records as custom payload (see extensions ) from the license holder's browser. On each change of the list of signed records the license holder would have to upload one's certificate to a vendor, which adds the new signed records. The vendor reissues a new certificate containing the new list of signed records as payload, and offers it as download to the license holder for installing.
Experimental Use This format is mainly about sharing and cross-service verification of license ownership (inter-service) than proving a purchase for guarantee claims or refund (intra-service). Thus it is intended to coexist with other signature or verification technologies, which may fall under bookkeeping law or similar. The format described in this document is not meant to fall under such regulations. Adaptors of this format are requested to experiment with the following of its methods or properties.
Evolving Methods of Sharing and Synchronisation As seen in there are different ways to store and exchange signed records. Additionally to the suggested methods there MAY evolve other standards of sharing signed records. To simplify research on the evolvement of those methods, adapters SHOULD update . For example evolving methods may contain two-party techniques (i.e. communication only between service provider and license holder e.g. via file down- and upload) or involve third parties (identity service provider, cloud storage provider via WebDAV, and others).
Evolving Common Product Identifiers This document should motivate to find a consensus of commonly used product identifiers for . Even though the suggestions for identifier prefixes relate to publicly accessible databases, there MAY evolve proprietary formats as long as every system knows to which product an identifier refers. On consensus of identifier prefixes this document …
  • MUST be updated, if it replaces a suggested identifier prefix, or
  • SHOULD be updated, if a new identifier prefix is added.
Industry Support It may be difficult to gain wide industry support. Nevertheless this may not be a reason to dismiss this document, as protocols and technologies more and more evolve to open standards providing better interoperability. This document contributes to the movement. There are already service providers, which try to bundle offers of other service providers into one subscription e.g. MagentaTV bundles classic television with the offers of Amazon Prime Video, RTL+ and others (as of December 2022). This bundling requires (1) communication between the services, i.e. at least showing offers of other service providers, and (2) verification of eligibility of an offer for a certain user. The format specified in this document enables at least two things:
  1. Unlimited offers by enabling the inclusion of any other service provider, without having to implement another proprietary or vendor-specific format
  2. Saving costs for a content delivery network at each service provider by using each other's infrastructure based on geolocation
  3. Integrating each others service providers' offers and thus creating a unified and immersive experience to the user.
Especially as there is a trend to found creator-owned streaming offers of movie creators (e.g. Disney+ by Walt Disney Studios, Paramount+ by Paramount Studios, …), people might tend to select only one subscription for financial reasons. A single subscription may cost less than multiple subscriptions at different streaming service providers. This would lead to less offers for the user per price unit, loss of paid license fees for other service providers' offers, and less customers per service provider by preventing indirect customers. Indirect customers in this sense mean customers on a service provider A watching e.g. a movie offered by service provider B, where service provider B earns a small compensation for providing the movie on service A.
Peer-to-Peer Support The following suggestions are primarily for use on the license holder side, who has no force over copyright decisions. Thus their realisation may depend on the local jurisdiction. When extrapolating the concept of sharing resources, you could even transfer this format to peer to peer applications like WebTorrent. Unfortunately there are many media items shared via WebTorrent, which infringe copyright. By ensuring via the format in this document, that a WebTorrent client, which receives a media item, is also a license holder of this item, there may be ways to allow the use of WebTorrent for media streaming without copyright infringement. This would also allow to use media items, without both having to store them on a local disk as well as being bound to a single service provider. For example television recordings, which may be provided by different service providers, may be stored as signed records (in some jurisdictions with expiry date) for watching them at a later time. When the license holder would like to watch those recordings, it can go to any service provider, verify its license ownership with the signed record, and watch the recording.
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
Dismissal of registration should not affect publication of this document.
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 "items", containing a list of items 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, and
  • there SHOULD NOT be any unique identifiers for identifying the license holder, i.e. no customer numbers or IDs. You SHOULD rather use the suggested claims/properties in , because you cannot identify a person uniquely (some people might have the same name), but still can verify the persons license.
 References Normative References GS1 General Specifications GS1 Germany The Internet Movie Database IMDb.com, Inc. International Standard Book Number International ISBN Agency International Standard Name Identifier ISNI International Agency (ISNI-IA) Ltd. International Standard Recording Code International ISRC Agency JSON Lines OpenID Connect Core v1 The OpenID Foundation Informative References
Example: Records All examples use the following JWS header:
JWS header
For the signature the following ES256 keys are used:
Signature keys
Family-Shared Movie Rental The following example represents a record for the purchase of
  • the movie "Big Buck Bunny" referenced in the via "https://imdb.com/title/tt1254207"
  • purchased on the 1st January 2022 at 00:00:00 GMT
  • issued by a fictional service provider called "Example Media Company" (see "iss" property/claim in )
  • shared among the "Doe" family (see absence of first name or other license holder properties )
  • as a rental from the time of purchase until the same day at 23:59:59 GMT (inclusive).
Please note that per definition in the value of "exp" is the next second after the last valid second.
Example record
The example yields the following signed record:
Example signed record
Rental of a Physical Object This format may also be used for proving guarantee claims or sharing rentals of tools. By this any family member can lend and return the drill e.g. in the same household. The following demonstrates a rental of a physical object i.e. …
  • the rental from 1st January 2022 at 00:00:00 GMT to same day 23:59:59 GMT (inclusive)
  • of a drill with product ID 1234
  • at the local store "Example Tools Rental Store" with website "https://drill-store.example" used for product identifiers
  • for use at the address Example Street 123, 12345 Example-City, Example-Country.
As the Example Tools Rental Store doesn't have many items, it uses the top level folder in the url path for product IDs. In this case this follows the schema "https://drill-store.example/{ID}" instead of "https://drill-store.example/{CATEGORY}/{ID}".
Example record
The example yields the following signed record:
Example signed record
Custom Identity Fields The following example shows adding custom license holder properties in compliance with . The following demonstrates the …
  • purchase of the movie "Big Buck Bunny" referenced in the via "https://imdb.com/title/tt1254207"
  • by a user with email john.doe@example.com
  • on the 1st January 2022 at 00:01:05 GMT
  • at the streaming provider Example Streaming Provider.
Example record
The example yields the following signed record:
Example signed record
This signed record can now be uploaded to a different streaming service to not have to purchase the movie again at the other streaming service.
Birthday Voucher The following demonstrates a voucher for
  • a birthday gift of category "wood" and vendor-specific id "1234"
  • by Example Toys Store, which has its website on "https://toy-store.example",
  • for people born on 1st January 2000 GMT+0000
  • valid to fetch from the 1st January 2022 at 00:00:00 GMT to same day 23:59:59 GMT (inclusive).
Example record
The example yields the following signed record:
Example signed record
Multiple Objects If multiple records are issued by the same provider, they could also be unified into a single signed record.
Example record
This results in the following signed record.
Example signed record
Example: File An example file containing all example signed records above in minified format (i.e. without whitespaces) is containing the following:
Example signed records file