Internet-Draft PEF October 2022
Frank Expires 11 April 2023 [Page]
Internet Engineering Task Force
Intended Status:
M. J. Frank, Ed.

Purchase Exchange Format (PEF)


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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 11 April 2023.

Table of Contents

1. 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

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.

1.1. 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 [BCP14] when, and only when, they appear in all capitals, as shown here.

2. Terminology

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

Product object
JSON object containing product data
JSON object containing purchase information and a list of product objects
Signed Record
JSON Web Signature (JWS) [RFC7515] containing a record as payload

3. Record

Each record MUST be a JSON object [RFC8259] for later conversion to a JWS payload (see Section 5).

The following properties/claims of a record are REQUIRED:

issuer, as defined in Section 4.1.1 of [RFC7519]
timestamp of issuing for bookkeeping and maybe some legal requirements, as defined in Section 4.1.6 of [RFC7519]

The following properties of a record are OPTIONAL:

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

3.1. Timely Restrictions

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

timestamp from when the products are licensed for use, as defined in Section 4.1.5 of [RFC7519]
timestamp when the products' license will expire, as defined in Section 4.1.4 of [RFC7519]
seconds after which the record expires after first use / issuing, e.g. for time-flexible subscriptions or vouchers, as defined in Section 5.10.3 of [RFC9200]

3.2. 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 Section 5.1 of [OpenID.Connect.Core]:

  • 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.

4. Product Objects

The REQUIRED property/claim "products" MUST have a JSON array (as defined in Section 5 of [RFC8259]) as value, containing product objects. Product objects are JSON objects (see Section 4 of [RFC8259]) with specific properties as defined in this section.

4.1. 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:

Identifier: [IMDb] ID
Prefix: isrc://
Identifier: uppercase [ISRC]
Example: isrc://AA6Q7-20-00047


Identifier: uppercase [ISNI]
Prefix: isbn://
Identifier: alphanumeric-only [ISBN]
Example: isbn://123456789X
Prefix: app://
Identifier: application identifier
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.

4.2. 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:

product title e.g. movie title, song name
year of creation
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.

5. Signed Record

Above record doesn't provide data integrity. Thus the security of records depend on JSON Web Signatures (JWS) [RFC7515] as their carrier. A signed record is a JWS with its payload being a representation of the record according to Step 2 of Section 7.1 of [RFC7519]. 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 [RFC7519] 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 Section 2 of [RFC7515] 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 Section 4.1.9 of [RFC7515].

6. 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 [JSON.Lines], 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 [RFC4918]. 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:

7. IANA Considerations

7.1. Media Type Registration

IANA is asked to assign the media type "application/pef" in the "Media Types" registry in the manner described in [RFC6838], 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 Section 5.

  • Type name: application
  • Subtype name: pef
  • Required parameters: N/A
  • Optional parameters: N/A
  • Encoding considerations: 8bit; as JWS [RFC7515]
  • Security considerations: this document Section 8
  • 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, (REMOVE EMAIL BEFORE PUBLISHING)
  • Intended usage: COMMON
  • Restrictions on usage: N/A
  • Author: Maximilian Josef Frank
  • Change controller: Maximilian Josef Frank
  • Provisional registration: no

7.2. 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 Section 4).

8. Security Considerations

All the security considerations of JSON Web Signatures [RFC7515], also apply to this specification.

8.1. 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 Section 4.1.6 of [RFC7515]. 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.

8.2. License Holder

If the license holder (see Section 3.2) 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.

9. Privacy Considerations

This section uses terms from [RFC6973].

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, ...

10. References

10.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, .
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, .
[IMDb], Inc., "The Internet Movie Database", <>.
International ISBN Agency, "International Standard Book Number", <>.
ISNI International Agency (ISNI-IA) Ltd., "International Standard Name Identifier", <>.
International ISRC Agency, "International Standard Recording Code", <>.
Ward, I., "JSON Lines", <>.
The OpenID Foundation, "OpenID Connect Core v1", , <>.
Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, , <>.
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, , <>.
Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, , <>.
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <>.
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <>.
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <>.
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, , <>.

10.2. Informative References

Appendix A. 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.

 "iss":"Media Europe GmbH",
Figure 1: Example record

Author's Address

Maximilian Josef Frank (editor)