Internet-Draft PEF December 2022
Frank Expires 11 June 2023 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-frank-purchase-exchange-format-01
Published:
Intended Status:
Experimental
Expires:
Author:
M. J. Frank, Ed.

Purchase Exchange Format (PEF)

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.

▲

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

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

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.

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

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.

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

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

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

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

11. References

11.1. Normative References

[BCP14]
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, .
<https://www.rfc-editor.org/info/bcp14>
[GTIN]
GS1 Germany, "GS1 General Specifications", , <https://www.gs1.org/genspecs>.
[IMDb]
IMDb.com, Inc., "The Internet Movie Database", <https://imdb.com>.
[ISBN]
International ISBN Agency, "International Standard Book Number", <https://isbn-international.org>.
[ISNI]
ISNI International Agency (ISNI-IA) Ltd., "International Standard Name Identifier", <https://isni.org>.
[ISRC]
International ISRC Agency, "International Standard Recording Code", <https://isrc.ifpi.org>.
[JSON.Lines]
Ward, I., "JSON Lines", <https://jsonlines.org>.
[OpenID.Connect.Core]
The OpenID Foundation, "OpenID Connect Core v1", , <https://openid.net/specs/openid-connect-core-1_0.html>.
[RFC4514]
Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, DOI 10.17487/RFC4514, , <https://www.rfc-editor.org/info/rfc4514>.
[RFC4918]
Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, , <https://www.rfc-editor.org/info/rfc4918>.
[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, , <https://www.rfc-editor.org/info/rfc5280>.
[RFC6838]
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, , <https://www.rfc-editor.org/info/rfc6838>.
[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, , <https://www.rfc-editor.org/info/rfc6973>.
[RFC8259]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/info/rfc8259>.
[RFC7515]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <https://www.rfc-editor.org/info/rfc7515>.
[RFC7519]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/info/rfc7519>.
[RFC7595]
Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, , <https://www.rfc-editor.org/info/rfc7595>.
[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, , <https://www.rfc-editor.org/info/rfc9200>.
[STD66]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, .
<https://www.rfc-editor.org/info/std66>

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

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.

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.

{
 "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:

{"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