Internet Engineering Task Force M. J. Frank, Ed. Internet-Draft 8 December 2022 Intended status: Experimental Expires: 11 June 2023 Purchase Exchange Format (PEF) draft-frank-purchase-exchange-format-01 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 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. 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 June 2023. Copyright Notice 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 Frank Expires 11 June 2023 [Page 1] Internet-Draft PEF December 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Record . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Timely Restrictions . . . . . . . . . . . . . . . . . . . 5 3.2. License Holder . . . . . . . . . . . . . . . . . . . . . 5 4. Product Objects . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Identifier "id" . . . . . . . . . . . . . . . . . . . . . 6 4.2. Additional Information . . . . . . . . . . . . . . . . . 7 5. Signed Record . . . . . . . . . . . . . . . . . . . . . . . . 8 6. File Format and Synchronisation . . . . . . . . . . . . . . . 8 6.1. File . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Client Certificate . . . . . . . . . . . . . . . . . . . 9 7. Experimental Use . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Evolving Methods of Sharing and Synchronisation . . . . . 10 7.2. Evolving Common Product Identifiers . . . . . . . . . . . 10 7.3. Industry Support . . . . . . . . . . . . . . . . . . . . 10 7.4. Peer-to-Peer Support . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8.1. Media Type Registration . . . . . . . . . . . . . . . . . 11 8.2. Comment on "JSON Web Token Claims" Registry . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 13 9.2. License Holder . . . . . . . . . . . . . . . . . . . . . 13 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Example: Records . . . . . . . . . . . . . . . . . . 16 A.1. Family-Shared Movie Rental . . . . . . . . . . . . . . . 16 A.2. Rental of a Physical Object . . . . . . . . . . . . . . . 17 A.3. Custom Identity Fields . . . . . . . . . . . . . . . . . 19 A.4. Birthday Voucher . . . . . . . . . . . . . . . . . . . . 20 A.5. Multiple Objects . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Example: File . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 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 Frank Expires 11 June 2023 [Page 2] Internet-Draft PEF December 2022 * simplify and automate digital inheritance or (family) sharing across platforms (see Appendix A.1), * 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 Appendix A.2. 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. 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. Frank Expires 11 June 2023 [Page 3] Internet-Draft PEF December 2022 2. Terminology Naming conventions throughout this document of attributes include use for offline or non-media purchases. Product object JSON object containing product data, see Section 4 Record JSON object containing purchase information and a list of product objects, see Section 3 Signed Record JSON Web Signature (JWS) in JSON Serialisation format (Section 3.2 of [RFC7515]) containing a record as payload, see Section 5 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 Appendix A.2 for examples on physical objects. 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]. As the format in this document is for exchanging information, this field must be in string representation of Distinguished Names format [RFC4514] (e.g. "CN=Example Company"). For further examples have a look at the appendix Appendix A. 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 accessible URIs e.g. "https://seller.example/category/012345". Frank Expires 11 June 2023 [Page 4] Internet-Draft PEF December 2022 3.1. 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 Section 4.1.5 of [RFC7519] exp timestamp when the items' license will expire, as defined in Section 4.1.4 of [RFC7519] exi seconds after which the record expires after first use or 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. 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 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" and "locale" MAY be present. See Appendix A.1 for an example. Frank Expires 11 June 2023 [Page 5] Internet-Draft PEF December 2022 This list of license holder properties is not exhaustive, so you can add your own properties. Nevertheless all properties MUST be compatible with [OpenID.Connect.Core]. An example is given in Appendix A.3. Please be aware of the privacy considerations in Section 10 for identifying data. 4. Product Objects The REQUIRED property/claim "items" 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. For signing multiple product objects in a single signed record see Appendix A.5. 4.1. Identifier "id" Each product object MUST have the property "id". This is a string containing a unique URI-style product identifier (see [STD66]). 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 [RFC7595] 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: [IMDb] ID Example: https://imdb.com/title/tt1254207 music Prefix: https://isrcsearch.ifpi.org/#!/search?tab=lookup&isrcCode= Identifier: uppercase [ISRC], only alphanumeric characters Example: https://isrcsearch.ifpi.org/#!/search?tab=lookup&isrcCode =AA6Q72000047 or Prefix: https://isni.org/isni/ Identifier: uppercase [ISNI] Example: https://isni.org/isni/000000012146438X Frank Expires 11 June 2023 [Page 6] Internet-Draft PEF December 2022 book Prefix: https://isbndb.com/book/ Identifier: alphanumeric-only [ISBN] 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: [GTIN] (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 Section 4.2), 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 Appendix A.2 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. 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 or song name year year of creation Frank Expires 11 June 2023 [Page 7] Internet-Draft PEF December 2022 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. 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. To allow for JSON representations of signed records the more strict specification of a JSON Web Token [RFC7519] 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 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" (without quotation marks) 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, there may be different formats of exchanging multiple signed records. 6.1. File A file containing the signed records 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. See Appendix B for an example. Frank Expires 11 June 2023 [Page 8] Internet-Draft PEF December 2022 Synchronisation MAY be supported by product vendors or services through WebDAV file synchronisation [RFC4918]. 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 [JSON.Lines]) with empty lines as connection keep- alive, * avoid file writing collisions by appending signed records without knowing the file content. 6.2. 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 Section 5.2 of [RFC5280]) 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. 7. 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. Frank Expires 11 June 2023 [Page 9] Internet-Draft PEF December 2022 7.1. Evolving Methods of Sharing and Synchronisation As seen in Section 6 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 Section 6. 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). 7.2. Evolving Common Product Identifiers This document should motivate to find a consensus of commonly used product identifiers for Section 4.1. 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. 7.3. 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 Frank Expires 11 June 2023 [Page 10] Internet-Draft PEF December 2022 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. 7.4. 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. 8. IANA Considerations 8.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. Frank Expires 11 June 2023 [Page 11] Internet-Draft PEF December 2022 * 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 9 * 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. Frank Expires 11 June 2023 [Page 12] Internet-Draft PEF December 2022 8.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 "items", containing a list of items for which to prove license-ownership (see Section 4). 9. Security Considerations All the security considerations of JSON Web Signatures [RFC7515], also apply to this specification. 9.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. 9.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. 10. 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 June 2023 [Page 13] Internet-Draft PEF December 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, 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 Section 3.2, because you cannot identify a person uniquely (some people might have the same name), but still can verify the persons license. 11. References 11.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. [GTIN] GS1 Germany, "GS1 General Specifications", 2014, . [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, . Frank Expires 11 June 2023 [Page 14] Internet-Draft PEF December 2022 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, DOI 10.17487/RFC4514, June 2006, . [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, June 2007, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [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, . [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, . Frank Expires 11 June 2023 [Page 15] Internet-Draft PEF December 2022 [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, . [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. 11.2. Informative References Appendix A. Example: Records All examples use the following JWS header: { "alg":"ES256" } Figure 1: JWS header For the signature the following ES256 keys are used: -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEVs/o5+uQbTjL3chynL4wXgUg2R9 q9UU8I5mEovUf86QZ7kOBIjJwqnzD1omageEHWwHdBO6B+dFabmdT9POxg== -----END PUBLIC KEY----- -----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgevZzL1gdAFr88hb2 OF/2NxApJCzGCEDdfSp6VQO30hyhRANCAAQRWz+jn65BtOMvdyHKcvjBeBSDZH2r 1RTwjmYSi9R/zpBnuQ4EiMnCqfMPWiZqB4QdbAd0E7oH50VpuZ1P087G -----END PRIVATE KEY----- Figure 2: Signature keys A.1. Family-Shared Movie Rental The following example represents a record for the purchase of * the movie "Big Buck Bunny" referenced in the [IMDb] via "https://imdb.com/title/tt1254207" * purchased on the 1st January 2022 at 00:00:00 GMT Frank Expires 11 June 2023 [Page 16] Internet-Draft PEF December 2022 * issued by a fictional service provider called "Example Media Company" (see "iss" property/claim in Section 3) * shared among the "Doe" family (see absence of first name or other license holder properties Section 3.2) * as a rental from the time of purchase until the same day at 23:59:59 GMT (inclusive). Please note that per definition in Section 4.1.4 of [RFC7519] the value of "exp" is the next second after the last valid second. { "iss": "CN=Example Media Company", "iat": 1640995200, "exp": 1641081600, "family_name": "Doe", "items": [ { "id": "https://imdb.com/title/tt1254207" } ] } Figure 3: Example record The example yields the following signed record: { "protected": "eyJhbGciOiJFUzI1NiJ9", "payload": "eyJpc3MiOiJDTj1FeGFtcGxlIE1lZGlhIENvbXBhbnkiLCJpYXQiOjE2 NDA5OTUyMDAsImV4cCI6MTY0MTA4MTYwMCwiZmFtaWx5X25hbWUiOiJEb2UiLCJpdGVtc yI6W3siaWQiOiJodHRwczovL2ltZGIuY29tL3RpdGxlL3R0MTI1NDIwNyJ9XX0", "signature": "q9-F4ZZPSf9VJOGvTuMeuSCtgcZC1hNl2k6PLVlmT8DnjDMj1TKyS0 Fh0bvJbjoZ4OaKCqzeXW1o9QHBHJN8BA" } Figure 4: Example signed record A.2. 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) Frank Expires 11 June 2023 [Page 17] Internet-Draft PEF December 2022 * 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}". { "iss": "CN=Example Tools Rental Store", "iat": 1640995200, "exp": 1641081600, "address": { "street_address": "Example Street 123", "locality": "Example-City", "country": "Example-Country" }, "items": [ { "id": "https://drill-store.example/1234" } ] } Figure 5: Example record The example yields the following signed record: { "protected": "eyJhbGciOiJFUzI1NiJ9", "payload": "eyJpc3MiOiJDTj1FeGFtcGxlIFRvb2xzIFJlbnRhbCBTdG9yZSIsImlh dCI6MTY0MDk5NTIwMCwiZXhwIjoxNjQxMDgxNjAwLCJhZGRyZXNzIjp7InN0cmVldF9hZ GRyZXNzIjoiRXhhbXBsZSBTdHJlZXQgMTIzIiwibG9jYWxpdHkiOiJFeGFtcGxlLUNpdH kiLCJjb3VudHJ5IjoiRXhhbXBsZS1Db3VudHJ5In0sIml0ZW1zIjpbeyJpZCI6Imh0dHB zOi8vZHJpbGwtc3RvcmUuZXhhbXBsZS8xMjM0In1dfQ", "signature": "24wxHovyPZBAa57KlFCchnhsCIBv7AfRmjLFYRrQi-1lyvrEt5xtEZ nsZntZUxW9751-XT0dYsR_yylQSVdhPg" } Figure 6: Example signed record Frank Expires 11 June 2023 [Page 18] Internet-Draft PEF December 2022 A.3. Custom Identity Fields The following example shows adding custom license holder properties in compliance with [OpenID.Connect.Core]. The following demonstrates the ... * purchase of the movie "Big Buck Bunny" referenced in the [IMDb] 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. { "iss": "CN=Example Streaming Provider", "iat": 1640995265, "email": "john.doe@example.com", "items": [ { "id": "https://imdb.com/title/tt1254207" } ] } Figure 7: Example record The example yields the following signed record: { "protected": "eyJhbGciOiJFUzI1NiJ9", "payload": "eyJpc3MiOiJDTj1FeGFtcGxlIFN0cmVhbWluZyBQcm92aWRlciIsImlh dCI6MTY0MDk5NTI2NSwiZW1haWwiOiJqb2huLmRvZUBleGFtcGxlLmNvbSIsIml0ZW1zI jpbeyJpZCI6Imh0dHBzOi8vaW1kYi5jb20vdGl0bGUvdHQxMjU0MjA3In1dfQ", "signature": "wASbTxXnPyhfBaMPI26ha3tyPvDDOHdxY6aXSej3umBKLl5cu68mcE AjkCJG7uo1HwOI_LOnBG8gLbzv4sHULw" } Figure 8: 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. Frank Expires 11 June 2023 [Page 19] Internet-Draft PEF December 2022 A.4. 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). { "iss":"CN=Example Toys Store", "iat":1640995200, "exp":1641081600, "birthdate":"2000-01-01", "items":[ { "id":"https://toy-store.example/wood/1234" } ] } Figure 9: Example record The example yields the following signed record: { "protected": "eyJhbGciOiJFUzI1NiJ9", "payload": "eyJpc3MiOiJDTj1FeGFtcGxlIFRveXMgU3RvcmUiLCJpYXQiOjE2NDA5 OTUyMDAsImV4cCI6MTY0MTA4MTYwMCwiYmlydGhkYXRlIjoiMjAwMC0wMS0wMSIsIml0Z W1zIjpbeyJpZCI6Imh0dHBzOi8vdG95LXN0b3JlLmV4YW1wbGUvd29vZC8xMjM0In1dfQ ", "signature": "vv4Cz2TfSxWuVqJZzER_h0wQq1MfRM9Dfsik9dAFuox0A_Zx1pxU8G vtkPypY8RsfHcA97yCQbXE5hRS6KFdmg" } Figure 10: Example signed record A.5. Multiple Objects If multiple records are issued by the same provider, they could also be unified into a single signed record. Frank Expires 11 June 2023 [Page 20] Internet-Draft PEF December 2022 { "iss": "CN=Example Streaming Provider", "iat": 1640995265, "media": [ { "id": "https://imdb.com/title/tt1254207" }, { "id": "https://imdb.com/title/tt1234567" } ] } Figure 11: Example record This results in the following signed record. { "protected": "eyJhbGciOiJFUzI1NiJ9", "payload": "eyJpc3MiOiJDTj1FeGFtcGxlIFN0cmVhbWluZyBQcm92aWRlciIsImlh dCI6MTY0MDk5NTI2NSwiaXRlbXMiOlt7ImlkIjoiaHR0cHM6Ly9pbWRiLmNvbS90aXRsZ S90dDEyNTQyMDcifSx7ImlkIjoiaHR0cHM6Ly9pbWRiLmNvbS90aXRsZS90dDEyMzQ1Nj cifV19", "signature": "735nWFtgfYZcpB7BmNUiaV5T7AWpuGAbF8cFwqPRHNWcN6rsxAjuTI XQNEn4DY-zpGvh5fOubf9ARpZAil3bxg" } Figure 12: Example signed record Appendix B. Example: File An example file containing all example signed records above in minified format (i.e. without whitespaces) is containing the following: Frank Expires 11 June 2023 [Page 21] Internet-Draft PEF December 2022 {"protected":"eyJhbGciOiJFUzI1NiJ9","payload":"eyJpc3MiOiJDTj1FeGFtcG xlIE1lZGlhIENvbXBhbnkiLCJpYXQiOjE2NDA5OTUyMDAsImV4cCI6MTY0MTA4MTYwMCw iZmFtaWx5X25hbWUiOiJEb2UiLCJpdGVtcyI6W3siaWQiOiJodHRwczovL2ltZGIuY29t L3RpdGxlL3R0MTI1NDIwNyJ9XX0","signature": "q9-F4ZZPSf9VJOGvTuMeuSCtgc ZC1hNl2k6PLVlmT8DnjDMj1TKyS0Fh0bvJbjoZ4OaKCqzeXW1o9QHBHJN8BA"} {"protected":"eyJhbGciOiJFUzI1NiJ9","payload":"eyJpc3MiOiJDTj1FeGFtcG xlIFRvb2xzIFJlbnRhbCBTdG9yZSIsImlhdCI6MTY0MDk5NTIwMCwiZXhwIjoxNjQxMDg xNjAwLCJhZGRyZXNzIjp7InN0cmVldF9hZGRyZXNzIjoiRXhhbXBsZSBTdHJlZXQgMTIz IiwibG9jYWxpdHkiOiJFeGFtcGxlLUNpdHkiLCJjb3VudHJ5IjoiRXhhbXBsZS1Db3Vud HJ5In0sIml0ZW1zIjpbeyJpZCI6Imh0dHBzOi8vZHJpbGwtc3RvcmUuZXhhbXBsZS8xMj M0In1dfQ","signature":"24wxHovyPZBAa57KlFCchnhsCIBv7AfRmjLFYRrQi-1lyv rEt5xtEZnsZntZUxW9751-XT0dYsR_yylQSVdhPg"} {"protected":"eyJhbGciOiJFUzI1NiJ9","payload":"eyJpc3MiOiJDTj1FeGFtcG xlIFN0cmVhbWluZyBQcm92aWRlciIsImlhdCI6MTY0MDk5NTI2NSwiZW1haWwiOiJqb2h uLmRvZUBleGFtcGxlLmNvbSIsIml0ZW1zIjpbeyJpZCI6Imh0dHBzOi8vaW1kYi5jb20v dGl0bGUvdHQxMjU0MjA3In1dfQ","signature":"wASbTxXnPyhfBaMPI26ha3tyPvDD OHdxY6aXSej3umBKLl5cu68mcEAjkCJG7uo1HwOI_LOnBG8gLbzv4sHULw"} {"protected":"eyJhbGciOiJFUzI1NiJ9","payload":"eyJpc3MiOiJDTj1FeGFtcG xlIFRveXMgU3RvcmUiLCJpYXQiOjE2NDA5OTUyMDAsImV4cCI6MTY0MTA4MTYwMCwiYml ydGhkYXRlIjoiMjAwMC0wMS0wMSIsIml0ZW1zIjpbeyJpZCI6Imh0dHBzOi8vdG95LXN0 b3JlLmV4YW1wbGUvd29vZC8xMjM0In1dfQ","signature":"vv4Cz2TfSxWuVqJZzER_ h0wQq1MfRM9Dfsik9dAFuox0A_Zx1pxU8GvtkPypY8RsfHcA97yCQbXE5hRS6KFdmg"} {"protected":"eyJhbGciOiJFUzI1NiJ9","payload":"eyJpc3MiOiJDTj1FeGFtcG xlIFN0cmVhbWluZyBQcm92aWRlciIsImlhdCI6MTY0MDk5NTI2NSwiaXRlbXMiOlt7Iml kIjoiaHR0cHM6Ly9pbWRiLmNvbS90aXRsZS90dDEyNTQyMDcifSx7ImlkIjoiaHR0cHM6 Ly9pbWRiLmNvbS90aXRsZS90dDEyMzQ1NjcifV19","signature":"735nWFtgfYZcpB 7BmNUiaV5T7AWpuGAbF8cFwqPRHNWcN6rsxAjuTIXQNEn4DY-zpGvh5fOubf9ARpZAil3 bxg"} Figure 13: Example signed records file Author's Address Maximilian Josef Frank (editor) Germany Email: contact@script4all.com Frank Expires 11 June 2023 [Page 22]