| Internet-Draft | PEF | October 2022 |
| Frank | Expires 11 April 2023 | [Page] |
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.¶
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 (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
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.¶
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.¶
Naming conventions throughout this document of attributes include use for offline or non-media purchases.¶
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:¶
The following properties of a record are OPTIONAL:¶
Timely restrictions are useful for rentals or subscriptions of products. The following properties of a purchase object are OPTIONAL:¶
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]:¶
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.¶
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.¶
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:¶
With this extendable identifier scheme you can ...¶
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:¶
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.¶
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].¶
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:¶
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.¶
Additional information:¶
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).¶
All the security considerations of JSON Web Signatures [RFC7515], also apply to this specification.¶
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.¶
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.¶
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, ...¶
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"
}
]
}