Internet Engineering Task Force M. J. Frank, Ed. Internet-Draft 8 October 2022 Intended status: Experimental Expires: 11 April 2023 Purchase Exchange Format (PEF) draft-frank-purchase-exchange-format-00 Abstract 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 https://datatracker.ietf.org/drafts/current/. 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. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Frank Expires 11 April 2023 [Page 1] Internet-Draft PEF October 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Record . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Timely Restrictions . . . . . . . . . . . . . . . . . . . 4 3.2. License Holder . . . . . . . . . . . . . . . . . . . . . 4 4. Product Objects . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Identifier "id" . . . . . . . . . . . . . . . . . . . . . 5 4.2. Additional Information . . . . . . . . . . . . . . . . . 6 5. Signed Record . . . . . . . . . . . . . . . . . . . . . . . . 7 6. File Format and Synchronisation . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 8 7.2. Comment on "JSON Web Token Claims" Registry . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 8.2. License Holder . . . . . . . . . . . . . . . . . . . . . 9 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 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 * 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), Frank Expires 11 April 2023 [Page 2] Internet-Draft PEF October 2022 * 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. 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 Record JSON object containing purchase information and a list of product objects Signed Record JSON Web Signature (JWS) [RFC7515] containing a record as payload Frank Expires 11 April 2023 [Page 3] Internet-Draft PEF October 2022 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: iss issuer, as defined in Section 4.1.1 of [RFC7519] iat 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: jti 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: nbf timestamp from when the products are licensed for use, as defined in Section 4.1.5 of [RFC7519] exp timestamp when the products' license will expire, as defined in Section 4.1.4 of [RFC7519] exi 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]: Frank Expires 11 April 2023 [Page 4] Internet-Draft PEF October 2022 * 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: movie Prefix: https://imdb.com/title/ Identifier: [IMDb] ID Example: https://imdb.com/title/tt1254207 music Prefix: isrc:// Identifier: uppercase [ISRC] Example: isrc://AA6Q7-20-00047 or Frank Expires 11 April 2023 [Page 5] Internet-Draft PEF October 2022 Prefix: https://isni.org/isni/ Identifier: uppercase [ISNI] Example: https://isni.org/isni/000000012146438X book Prefix: isbn:// Identifier: alphanumeric-only [ISBN] 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. 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: 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. Frank Expires 11 April 2023 [Page 6] Internet-Draft PEF October 2022 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: * keeping a history of purchases, * enable (immutable) streaming of the purchase exchange format line by line (see [JSON.Lines]) with empty lines as connection keep- alive, * avoid file writing collisions by appending signed records without knowing the file content. Frank Expires 11 April 2023 [Page 7] Internet-Draft PEF October 2022 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, contact@script4all.com (REMOVE EMAIL BEFORE PUBLISHING) * Intended usage: COMMON * Restrictions on usage: N/A * Author: Maximilian Josef Frank * Change controller: Maximilian Josef Frank Frank Expires 11 April 2023 [Page 8] Internet-Draft PEF October 2022 * 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, ... Frank Expires 11 April 2023 [Page 9] Internet-Draft PEF October 2022 * 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. 10. References 10.1. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [IMDb] IMDb.com, Inc., "The Internet Movie Database", . [ISBN] International ISBN Agency, "International Standard Book Number", . [ISNI] ISNI International Agency (ISNI-IA) Ltd., "International Standard Name Identifier", . [ISRC] International ISRC Agency, "International Standard Recording Code", . [JSON.Lines] Ward, I., "JSON Lines", . [OpenID.Connect.Core] The OpenID Foundation, "OpenID Connect Core v1", 2014, . [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, June 2007, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . Frank Expires 11 April 2023 [Page 10] Internet-Draft PEF October 2022 [RFC6973] 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, July 2013, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC9200] 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, August 2022, . 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", "iat":1640995200, "exp":1641081600, "family_name":"Doe", "media":[ { "id":"https://imdb.com/title/tt1254207" } ] } Frank Expires 11 April 2023 [Page 11] Internet-Draft PEF October 2022 Figure 1: Example record Author's Address Maximilian Josef Frank (editor) Germany Email: contact@script4all.com Frank Expires 11 April 2023 [Page 12]