Internet DRAFT - draft-frank-purchase-exchange-format
draft-frank-purchase-exchange-format
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.
<https://www.rfc-editor.org/info/bcp14>
[GTIN] GS1 Germany, "GS1 General Specifications", 2014,
<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", 2014,
<https://openid.net/specs/openid-connect-core-1_0.html>.
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,
<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, June 2007,
<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, May 2008,
<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, January 2013,
<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, July 2013,
<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, December 2017,
<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, May
2015, <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, May 2015,
<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, June 2015,
<https://www.rfc-editor.org/info/rfc7595>.
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,
<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, January 2005.
<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
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]
