OAuth Status Assertions
draft-demarco-oauth-status-assertions-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Giuseppe De Marco , Orie Steele , Francesco Marino , Marina Adomeit | ||
| Last updated | 2024-12-20 | ||
| Replaces | draft-demarco-oauth-status-attestations, draft-demarco-status-attestations | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-demarco-oauth-status-assertions-03
Network Working Group G. D. Marco
Internet-Draft Dipartimento per la trasformazione digitale
Intended status: Informational O. Steele
Expires: 23 June 2025 Transmute
F. Marino
Istituto Poligrafico e Zecca dello Stato
M. Adomeit
SUNET
20 December 2024
OAuth Status Assertions
draft-demarco-oauth-status-assertions-03
Abstract
Status Assertion is a signed object that demonstrates the validity
status of a Digital Credential. These assertions are periodically
provided to Holders, who can present these to Credential Verifier
along with the corresponding Digital Credentials. The approach
outlined in this document makes the Credential Verifier able to check
the status, such as the non-revocation, of a Digital Credential
without requiring to query any third-party entities.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://peppelinux.github.io/draft-demarco-oauth-status-assertions/
draft-demarco-oauth-status-assertions.html. Status information for
this document may be found at https://datatracker.ietf.org/doc/draft-
demarco-oauth-status-assertions/.
Source for this draft and an issue tracker can be found at
https://github.com/peppelinux/draft-demarco-oauth-status-assertions.
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/.
Marco, et al. Expires 23 June 2025 [Page 1]
Internet-Draft OAuth Status Assertions December 2024
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 23 June 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Proof of Possession of a Digital Credential . . . . . . . . . 6
7. Status Assertion Request . . . . . . . . . . . . . . . . . . 7
8. Status Assertion Response . . . . . . . . . . . . . . . . . . 11
9. Status Assertion Error . . . . . . . . . . . . . . . . . . . 12
9.1. Rationale about the Unsigned Status Assertion Errors . . 14
9.2. Status Assertion Error Values . . . . . . . . . . . . . . 15
10. Status Assertion . . . . . . . . . . . . . . . . . . . . . . 15
11. Interoperability of Issuers Supporting Status Assertions . . 19
11.1. Issuer Metadata . . . . . . . . . . . . . . . . . . . . 19
11.2. Issued Digital Credentials . . . . . . . . . . . . . . . 20
11.2.1. Issuer Implementation Considerations . . . . . . . . 21
12. Presenting Status Assertions . . . . . . . . . . . . . . . . 21
13. Considerations on Revocation Verification . . . . . . . . . . 22
14. Detailed Status Assertions . . . . . . . . . . . . . . . . . 23
15. Security Considerations . . . . . . . . . . . . . . . . . . . 24
16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
16.1. Privacy Consideration: Status Assertion Request
Opacity . . . . . . . . . . . . . . . . . . . . . . . . 25
16.2. Privacy Consideration: Opacity of Status Assertion
Content . . . . . . . . . . . . . . . . . . . . . . . . 25
Marco, et al. Expires 23 June 2025 [Page 2]
Internet-Draft OAuth Status Assertions December 2024
16.3. Unlinkability and Reusability of Status Assertions . . . 26
16.4. Untrackability by Digital Credential Issuers and the
"Phone Home" Problem . . . . . . . . . . . . . . . . . . 26
16.5. Minimization of Data Exposure . . . . . . . . . . . . . 27
16.6. Resistance to Enumeration Attacks . . . . . . . . . . . 27
16.7. Validity Reasons . . . . . . . . . . . . . . . . . . . . 27
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
17.1. JSON Web Token Claims Registration . . . . . . . . . . . 27
17.2. Media Type Registration . . . . . . . . . . . . . . . . 28
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
18.1. Normative References . . . . . . . . . . . . . . . . . . 34
18.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 36
Appendix B. Document History . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction
Status Assertions show the status of Digital Credentials, whether in
JSON Web Tokens (JWT) or CBOR Web Tokens (CWT) format. Status
Assertions function similarly to OCSP Stapling ([RFC6066]), allowing
Holders to present to the Relying Parties time-stamped assertions
provided by the Issuer. The approach outlined in this specification
enables the verification of Digital Credentials against revocation
without direct queries to third-party systems, enhancing privacy,
reducing latency, and faciliting offline verification.
The figure below illustrates the process by which a Holder, such as a
wallet instance, requests and obtains a Status Assertion from the
Issuer.
+----------------+ +------------------+
| | Requests Status Assertions | |
| |----------------------------->| |
| Holder | | Issuer |
| | Status Assertions | |
| |<-----------------------------| |
+----------------+ +------------------+
*Figure 1*: Status Assertion Issuance Flow.
The figure below illustrates the process by which a Holder presents
the Status Assertion along with the corresponding Digital Credential.
Marco, et al. Expires 23 June 2025 [Page 3]
Internet-Draft OAuth Status Assertions December 2024
+----------------+ +------------------+
| | Presents Digital Credential | |
| Holder | and Status Assertion | Verifier |
| |---------------------------->| |
+----------------+ +------------------+
*Figure 2*: Status Assertion Presentation Flow.
In summary, the Issuer provides the Holder with a Status Assertion,
which is linked to a Digital Credential. This enables the Holder to
present both the Digital Credential and its Status Assertion to a
Credential Verifier as proof of the Digital Credential's validity
status.
2. Conventions and Definitions
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
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology
This specification uses the terms "End-User", "Entity" as defined by
OpenID Connect Core [OpenID.Core], the term "JSON Web Token (JWT)"
defined by JSON Web Token (JWT) [RFC7519], the term "CBOR Web Token
(CWT)" defined in [RFC8392], "Client" as defined [RFC6749], "Holder",
"Verifiable Presentation" defined in [OpenID4VP].
Digital Credential: A set of one or more claims about a subject
issued by an Issuer. Alternative names are "Verifiable
Credential" or "Credential".
Issuer: Entity that is responsible for the issuance of the Digital
Credentials. The Issuer is responsible for the lifecycle of their
issued Digital Credentials and their validity status and
responsible for issuance of related Status Assertions.
Alternative name is "Credential Issuer".
Verifier: Entity that relies on the validity of the Digital
Credentials presented to it. This Entity, verifies the
authenticity and validity of the Digital Credentials, including
their revocation status, before accepting them. Alternative names
are "Relying Party" and "Credential Verifier".
Wallet Instance: The digital Wallet in control of a User, also known
Marco, et al. Expires 23 June 2025 [Page 4]
Internet-Draft OAuth Status Assertions December 2024
as Wallet. It securely stores the User's Digital Credentials. It
can present Digital Credentials to Verifiers and request Status
Assertions from Issuers under the control of the User. For the
purposes of this specification, the Wallet Instance is considered
as a Client.
4. Rationale
There are cases where the Verifier only needs to check the revocation
status of a Digital Credential at the time of presentation, and
therefore it should not be allowed to check the status of a Digital
Credential over time due to some privacy constraints, in compliance
with national privacy regulations.
For instance, consider a scenario where a Verifier's repeated access
to a status list, such as the one defined in
[draft-ietf-oauth-status-list] to check the revocation status of a
Digital Credential could be deemed as excessive monitoring of the
End-User's activities.
This could potentially infringe upon the End-User's right to privacy,
as outlined in [ECHR-ART8] and in the the European Union's General
Data Protection Regulation [GDPR], by creating a detailed profile of
the End-User's Digital Credential status without explicit consent for
such continuous surveillance.
5. Requirements
The general requirements for the implementation of Status Assertion
are listed in this section. The Status Assertion:
* notifies the Holder about the status of their Digital Credential,
because the Holder MUST be informed by the Issuers of any changes
in the status of their Digital Credentials.
* SHOULD be presented in conjunction with the Digital Credential.
* MUST include information that links it to the referenced Digital
Credential.
* MUST be timestamped with its issuance datetime, using a timestamp
which is at or after the time of Digital Credential issuance which
it refers.
* MUST contain the expiration datetime after which the Status
Assertion MUST NOT be considered valid anymore, and the Digital
Credential referred to SHOULD NOT be considered as having a valid
status, unless there exists some specific Verifier policy that
Marco, et al. Expires 23 June 2025 [Page 5]
Internet-Draft OAuth Status Assertions December 2024
provides stronger guidance. The expiration datetime MUST be
superior to the Status Assertion issuance datetime and it MUST end
before the expiration datetime of the Digital Credential.
* MAY contain the _not before time_ parameter, specifying the time
from which the Status Assertion MUST be considered valid and
evaluable.
* MUST enable the offline use cases by employing validation using a
cryptographic signature and the cryptographic public key of the
Issuer.
* SHOULD NOT contain personal information about the User, that isn't
already made available to the Verifier, who owns the Digital
Credential to which the Status Assertion refers.
* MUST NOT contain any information regarding the Verifier to whom it
may be presented, such as disclose the Verifier identifier to
specify the intended audience.
6. Proof of Possession of a Digital Credential
The concept of Proof of Possession (PoP) of a Digital Credential
within the framework of the Status Assertion specification
encompasses a broader perspective than merely possessing the digital
bytes of the Digital Credential.
It involves demonstrating rightful control or ownership over the
Digital Credential, which can manifest in various forms depending on
the technology employed and the nature of the Digital Credential
itself. For instance, a Digital Credential could be presented
visually (de-visu) with a personal portrait serving as a binding
element.
While this specification does not prescribe any additional methods
for the proof of possession of the Digital Credential, it aims to
offer guidance for concrete implementations utilizing common proof of
possession mechanisms. This includes, but is not limited to:
1. Having the digital representation of the Digital Credential (the
bytes).
2. Controlling the confirmation method of the Digital Credential,
using the Digital Credential's cnf claim.
The essence of requiring proof of possession over the Digital
Credential through the confirmation method, such has proving the
control of the cryptographic material related to a Digital
Marco, et al. Expires 23 June 2025 [Page 6]
Internet-Draft OAuth Status Assertions December 2024
Credential, is to ensure that the entity in possession of the Digital
Credential can execute actions exclusively reserved to the legitimate
Holder. The dual-layered approach of requiring both possession of
the Digital Credential and control over it, reinforces the security
and integrity of the Status Assertion process. This ensures that the
Holder requesting a Status Assertion is indeed the same Holder to
which the Digital Credential was originally issued, affirming the
authenticity and rightful possession of the Digital Credential.
7. Status Assertion Request
The following diagram shows the Wallet Instance requesting a Status
Assertion to an Issuer, related to a specific Digital Credential
issued by the same Issuer.
+-------------------+ +-------------------+
| Wallet Instance | | Issuer |
+--------+----------+ +----------+--------+
| |
| HTTP POST /status-assertion-endpoint |
| status_assertion_requests = [$StatusAssertionRequest] |
+-------------------------------------------------------->
| |
| Status Assertion Responses [...] |
<--------------------------------------------------------+
| |
+--------+----------+ +----------+--------+
| Wallet Instance | | Issuer |
+-------------------+ +-------------------+
The Wallet Instance sends the Status Assertion request to the Issuer,
where:
* The request MUST contain the base64url encoded hash value of the
Digital Credential's Issuer signed part, such as the Issuer Signed
JWT using [SD-JWT.VC], or the Mobile Security Object using
[ISO.mdoc], for which the Status Assertion is requested, and
enveloped in a signed Status Assertion Request object.
* The Status Assertion Request object MUST be signed with the
private key corresponding to the confirmation claim assigned by
the Issuer and contained within the Digital Credential.
The Status Assertion Request object MUST contain the parameters and
claims defined in the following table.
Marco, et al. Expires 23 June 2025 [Page 7]
Internet-Draft OAuth Status Assertions December 2024
+========+==========================================+===========+
| Header | Description | Reference |
+========+==========================================+===========+
| *typ* | It MUST be set to status-assertion- | [RFC7516] |
| | request+jwt when JWT format is used. It | Section |
| | MUST be set to status-assertion- | 4.1.1, |
| | request+cwt when CWT format is used. | [RFC9596] |
+--------+------------------------------------------+-----------+
| *alg* | A digital signature algorithm identifier | [RFC7516] |
| | such as per IANA "JSON Web Signature and | Section |
| | Encryption Algorithms" registry. It | 4.1.1 |
| | MUST NOT be set to none or any symmetric | |
| | algorithm (MAC) identifier. | |
+--------+------------------------------------------+-----------+
Table 1
Marco, et al. Expires 23 June 2025 [Page 8]
Internet-Draft OAuth Status Assertions December 2024
+=====================+===========================================+=============+
|Payload |Description |Reference |
+=====================+===========================================+=============+
|*iss* |Status Assertion Request Issuer identifier.|[RFC9126], |
| |The value is supposed to be used for |[RFC7519] |
| |identifying the Wallet that has issued the | |
| |request. It is out of scope for this | |
| |document defining how this value should be | |
| |set. | |
+---------------------+-------------------------------------------+-------------+
|*aud* |It MUST be set with the Issuer Status |[RFC9126], |
| |Assertion endpoint URL as value that |[RFC7519] |
| |identify the intended audience. | |
+---------------------+-------------------------------------------+-------------+
|*exp* |UNIX Timestamp with the expiration time of |[RFC9126], |
| |the JWT. It MUST be superior to the value |[RFC7519], |
| |set for iat . |[RFC7515] |
+---------------------+-------------------------------------------+-------------+
|*iat* |UNIX Timestamp with the time of JWT/CWT |[RFC9126], |
| |issuance. |[RFC7519] |
+---------------------+-------------------------------------------+-------------+
|*jti* |Unique identifier when the Status Assertion|[RFC7519] |
| |Request is in JWT format, using the typ |Section 4.1.7|
| |parameter set to status-assertion- | |
| |request+jwt. | |
+---------------------+-------------------------------------------+-------------+
|*cti* |Unique identifier when the Status Assertion|[RFC7519] |
| |Request is in CWT format, using the typ |Section 4.1.7|
| |parameter set to status-assertion- | |
| |request+cwt. | |
+---------------------+-------------------------------------------+-------------+
|*credential_hash* |Hash value of the Digital Credential's |this |
| |Issuer signed part the Status Assertion is |specification|
| |bound to. | |
+---------------------+-------------------------------------------+-------------+
|*credential_hash_alg*|The hash algorithm MUST match the one |this |
| |specified in the |specification|
| |status.status_assertion.credential_hash_alg| |
| |claim of the Digital Credential for which | |
| |the Status Assertion is requested. | |
+---------------------+-------------------------------------------+-------------+
Table 2
Below is a non-normative example of a Status Assertion Request with
the JWT headers and payload represented without applying signature
and encoding:
Marco, et al. Expires 23 June 2025 [Page 9]
Internet-Draft OAuth Status Assertions December 2024
{
"alg": "ES256",
"typ": "status-assertion-request+jwt"
}
.
{
"iss": "0b434530-e151-4c40-98b7-74c75a5ef760",
"aud": "https://issuer.example.org/status-assertion-endpoint",
"iat": 1698744039,
"exp": 1698830439,
"jti": "6f204f7e-e453-4dfd-814e-9d155319408c",
"credential_hash": $hash-about-Issuer-Signed-JWT
"credential_hash_alg": "sha-256"
}
Below is a non-normative example of a Status Assertion Request object
in CWT format represented in CBOR diagnostic notation format
[RFC8152], where the CWT headers and payload are presented without
applying signature and encoding for better readability:
[
/ protected / << {
/ alg / 1: -7 / ES256 /
/ typ / 16: -7 / status-assertion-request+cwt /
} >>,
/ unprotected / {
},
/ payload / << {
/ iss / 1: 0b434530-e151-4c40-98b7-74c75a5ef760 /,
/ aud / 3: https://issuer.example.org/status-assertion-endpoint /,
/ iat / 6: 1698744039 /,
/ exp / 4: 1698830439 /,
/ cti / 7: 6f204f7e-e453-4dfd-814e-9d155319408c /,
/ credential_hash / 8: $hash-about-MobileSecurityObject /,
/ credential_hash_alg / 9: sha-256 /
} >>,
]
Below a non-normative example representing a Status Assertion Request
array with a single Status Assertion Request object in JWT format.
Marco, et al. Expires 23 June 2025 [Page 10]
Internet-Draft OAuth Status Assertions December 2024
POST /status-assertion-endpoint HTTP/1.1
Host: issuer.example.org
Content-Type: application/json
{
"status_assertion_requests" : [
$status_assertion_request,
$status_assertion_request, ...
]
}
The Status Assertion HTTP request can be sent to a single Issuer
regarding multiple Digital Credentials, and MUST contain a JSON
object with the member status_assertion_requests.
The status_assertion_requests MUST be set with an array of strings,
where each string within the array represents a Digital Credential
Status Assertion Request object.
The Issuer that receives the Status Assertion Request object MUST
validate that the Wallet Instance making the request is authorized to
request Status Assertions. Therefore the following requirements MUST
be satisfied:
* The Issuer MUST verify the compliance of all elements in the
status_assertion_requests object using the confirmation method
contained within the Digital Credential where the Status Assertion
Request object is referred to;
* The Issuer MUST verify that it is the legitimate Issuer of the
Digital Credential to which each Status Assertion Request object
refers.
8. Status Assertion Response
The response MUST include a JSON object with a member named
status_assertion_responses, which contains the Status Assertions and
or the Status Assertion Errors related to the request made by the
Wallet Instance. In the non-normative example below is represented
an HTTP Response with the status_assertion_responses JSON member:
Marco, et al. Expires 23 June 2025 [Page 11]
Internet-Draft OAuth Status Assertions December 2024
HTTP/1.1 200 OK
Content-Type: application/json
{
"status_assertion_responses": [
$status_assertion_response,
$status_assertion_response, ...
]
}
The member status_assertion_responses MUST be an array of strings,
where each of them represent a Status Assertion Response object, as
defined in the section Status Assertion (Section 10) or a Status
Assertion Error object, as defined in the section Status Error
(Section 9).
For each entry in the status_assertion_responses array, the following
requirements are met:
* Each element in the array MUST match the corresponding element in
the request array at the same position index to which it is
related, eg: _[requestAboutA, requestAboutB]_ may produce
_[responseAboutA, responseErrorAboutB]_.
* Each element MUST contain the error or the status of the
assertion, using the typ member set to "status-
assertion+{jwt,cwt}" or "status-assertion-error+{jwt,cwt}",
depending by the object type.
* The corresponding entry in the response MUST be of the same data
format as requested. For example, if the entry in the request is
"jwt", then the entry at the same position in the response MUST
also be "jwt".
* The corresponding entry in the response MUST NOT contain any
information regarding the Verifier to whom it may be presented,
such as the Verifier identifier as the intended audience.
9. Status Assertion Error
The Status Assertion Error MUST NOT be presented or provided to a
Verifier, the only audience of the Status Assertion Error is the
Holder of the Digital Credential that has requested the Status
Assertion. Therefore, it is not necessary that the Status Assertion
Error contains the claim aud; if present, it MUST be set to the same
value as the iss claim used by the Wallet in the corresponding Status
Assertion Request object.
Marco, et al. Expires 23 June 2025 [Page 12]
Internet-Draft OAuth Status Assertions December 2024
Below a non-normative example of a Status Assertion Error object in
JWT format, with the headers and payload represented in JSON and
without applying the signature.
{
"alg": "ES256",
"typ": "status-assertion-error+jwt",
"kid": "Issuer-JWK-KID"
}
.
{
"iss": "https://issuer.example.org",
"jti": "6f204f7e-e453-4dfd-814e-9d155319408c"
"credential_hash": $hash-about-Issuer-Signed-JWT,
"credential_hash_alg": "sha-256",
"error": "invalid_request_signature",
"error_description": "The verification of the request signature has failed."
}
}
The Status Assertion Error object MUST contain the parameters and
claims described in the table below:
+========+==========================================+===========+
| Header | Description | Reference |
+========+==========================================+===========+
| *typ* | REQUIRED. Depending on the related | [RFC7516] |
| | Status Assertion Request object format, | Section |
| | it MUST be set to status-assertion- | 4.1.1 |
| | error+jwt or status-assertion-error+cwt. | |
+--------+------------------------------------------+-----------+
| *alg* | REQUIRED. Algorithm used to verify the | [RFC7516] |
| | cryptographic signature of the Status | Section |
| | Assertion Error. Status Assertion Error | 4.1.1 |
| | that do not need to be signed SHOULD set | |
| | the alg value to none. For further | |
| | clarification about the requirement of | |
| | signing the Status Assertion Errors, see | |
| | Section Rationale About The Unsigned | |
| | Status Assertion Errors (Section 9.1). | |
+--------+------------------------------------------+-----------+
Table 3
Marco, et al. Expires 23 June 2025 [Page 13]
Internet-Draft OAuth Status Assertions December 2024
+=====================+===============================+=============+
|Payload | Description |Reference |
+=====================+===============================+=============+
|*iss* | REQUIRED. It MUST be set to |[RFC9126], |
| | the identifier of the Issuer. |[RFC7519] |
+---------------------+-------------------------------+-------------+
|*jti* | REQUIRED. Unique identifier |[RFC7519] |
| | for the JWT. |Section 4.1.7|
+---------------------+-------------------------------+-------------+
|*credential_hash* | REQUIRED. The hash value |this |
| | MUST match the one contained |specification|
| | in the Status Assertion | |
| | Request to which the Status | |
| | Assertion Error is related. | |
+---------------------+-------------------------------+-------------+
|*credential_hash_alg*| REQUIRED. The hash algorithm |this |
| | MUST match the one contained |specification|
| | in the Status Assertion | |
| | Request to which the Status | |
| | Assertion Error is related. | |
+---------------------+-------------------------------+-------------+
|*error* | REQUIRED. The value SHOULD |[RFC7519] |
| | be assigned with one of the |Section 4.1.7|
| | error types defined in | |
| | [RFC6749]Section 5.2 | |
| | (https://tools.ietf.org/html/ | |
| | rfc6749#section-5.2) or | |
| | defined in the Section Status | |
| | Assertion Error Values | |
| | (status-assertion-error- | |
| | values). | |
+---------------------+-------------------------------+-------------+
|*error_description* | OPTIONAL. Text that |[RFC7519] |
| | clarifies the nature of the |Section 4.1.7|
| | error in relation to the | |
| | error value. | |
+---------------------+-------------------------------+-------------+
Table 4
9.1. Rationale about the Unsigned Status Assertion Errors
To mitigate potential resource exhaustion attacks where an adversary
could issue hundreds of fake Status Assertion Requests to force an
Issuer to sign numerous Status Assertion Errors, it is advisable to
set the header parameter alg value to none for Status Assertion
Errors that do not require signatures. This approach conserves
computational resources and prevents abuse, especially in scenarios
Marco, et al. Expires 23 June 2025 [Page 14]
Internet-Draft OAuth Status Assertions December 2024
where the Issuer's implementation could be vulnerable to resource
exhaustion attacks. However, even if it is out of the scopes of this
specification determine in which the Status Error Assertion
signatures are necessary, when the Issuer signs the Status Assertion
Errors the Holder that received them MUST validate the signature.
9.2. Status Assertion Error Values
The error claim for the Status Assertion Error object MUST be set
with one of the values defined in the table below, in addition to the
values specified in [RFC6749]:
+=============================+======================+=============+
| Error Value | Description |Reference |
+=============================+======================+=============+
| *invalid_request_signature* | The Status Assertion |this |
| | Request signature |specification|
| | validation has | |
| | failed. This error | |
| | type is used when | |
| | the proof of | |
| | possession of the | |
| | Digital Credential | |
| | is found not valid | |
| | within the Status | |
| | Assertion Request. | |
+-----------------------------+----------------------+-------------+
| *credential_not_found* | The credential_hash |this |
| | value provided in |specification|
| | the Status Assertion | |
| | Request doesn't | |
| | match with any | |
| | active Digital | |
| | Credential. | |
+-----------------------------+----------------------+-------------+
| *unsupported_hash_alg* | The hash algorithm |this |
| | set in |specification|
| | credential_hash_alg | |
| | is not supported. | |
+-----------------------------+----------------------+-------------+
Table 5
10. Status Assertion
When a Status Assertion is requested to an Issuer, the Issuer checks
the status of the Digital Credential and creates a Status Assertion
bound to it.
Marco, et al. Expires 23 June 2025 [Page 15]
Internet-Draft OAuth Status Assertions December 2024
A non-normative example is given below where the format is JWT.
{
"alg": "ES256",
"typ": "status-assertion+jwt",
"kid": $ISSUER-JWKID
}
.
{
"iss": "https://issuer.example.org",
"iat": 1504699136,
"exp": 1504785536,
"credential_hash": $hash-about-Issuer-Signed-JWT,
"credential_hash_alg": "sha-256",
"credential_status_validity": 0,
"cnf": {
"jwk": {...}
}
}
The Status Assertion MUST contain the parameters and claims defined
below.
Marco, et al. Expires 23 June 2025 [Page 16]
Internet-Draft OAuth Status Assertions December 2024
+===========+====================================+===============+
| Header | Description | Reference |
| Parameter | | |
| Name | | |
+===========+====================================+===============+
| *alg* | A digital signature algorithm | [RFC7515], |
| | identifier such as per IANA "JSON | [RFC7517] |
| | Web Signature and Encryption | |
| | Algorithms" registry. It MUST NOT | |
| | be set to none or to a symmetric | |
| | algorithm (MAC) identifier. | |
+-----------+------------------------------------+---------------+
| *typ* | It MUST be set to status- | [RFC7515], |
| | assertion+jwt when JWT format is | [RFC7517] and |
| | used. It MUST be set to status- | this |
| | assertion+cwt when CWT format is | specification |
| | used. | |
+-----------+------------------------------------+---------------+
| *kid* | Unique identifier of the Issuer | [RFC7515] |
| | JWK. It is required when x5c or | |
| | other cryptographic public key | |
| | resolution identifiers are not | |
| | used. | |
+-----------+------------------------------------+---------------+
| *x5c* | X.509 certificate chain about the | [RFC7515] |
| | Issuer. It is required when kid | |
| | or other parameter are not used. | |
+-----------+------------------------------------+---------------+
Table 6
+==============================+====================+===============+
| Payload Claim Name | Description | Reference |
+==============================+====================+===============+
| *iss* | It MUST be set to | [RFC9126], |
| | the identifier of | [RFC7519] |
| | the Issuer. | |
+------------------------------+--------------------+---------------+
| *iat* | UNIX Timestamp | [RFC9126], |
| | with the time of | [RFC7519] |
| | the Status | |
| | Assertion | |
| | issuance. | |
+------------------------------+--------------------+---------------+
| *exp* | UNIX Timestamp | [RFC9126], |
| | with the | [RFC7519], |
| | expiration time | [RFC7515] |
| | of the JWT. It | |
Marco, et al. Expires 23 June 2025 [Page 17]
Internet-Draft OAuth Status Assertions December 2024
| | MUST be greater | |
| | than the value | |
| | set for iat. | |
+------------------------------+--------------------+---------------+
| *credential_hash* | Hash value of the | this |
| | Digital | specification |
| | Credential's | |
| | Issuer signed | |
| | part the Status | |
| | Assertion is | |
| | bound to. | |
+------------------------------+--------------------+---------------+
| *credential_hash_alg* | The hash | this |
| | algorithm MUST | specification |
| | match the one | |
| | contained in the | |
| | Status Assertion | |
| | Request to which | |
| | the Status | |
| | Assertion is | |
| | related. | |
+------------------------------+--------------------+---------------+
| *credential_status_validity* | Numerical value | this |
| | indicating the | specification |
| | validity of the | |
| | Digital | |
| | Credential linked | |
| | to the Status | |
| | Assertion, | |
| | describing its | |
| | state, mode, | |
| | condition or | |
| | stage. The value | |
| | MUST be from the | |
| | IANA registry (as | |
| | described in | |
| | Section 7.1 of | |
| | draft-ietf-oauth- | |
| | status-list). | |
| | Status validity | |
| | parameter is | |
| | REQUIRED, and the | |
| | Verifier MUST | |
| | verify its | |
| | presence and | |
| | value to assess | |
| | the Digital | |
| | Credential's | |
Marco, et al. Expires 23 June 2025 [Page 18]
Internet-Draft OAuth Status Assertions December 2024
| | validity. | |
+------------------------------+--------------------+---------------+
| *cnf* | JSON object | [RFC7800] |
| | containing | Section 3.1, |
| | confirmation | [RFC8747] |
| | methods. The | Section 3.1 |
| | sub-member | |
| | contained within | |
| | cnf member, such | |
| | as jwk for JWT | |
| | and Cose_Key for | |
| | CWT, MUST match | |
| | with the one | |
| | provided within | |
| | the related | |
| | Digital | |
| | Credential. | |
| | Other | |
| | confirmation | |
| | methods can be | |
| | utilized when the | |
| | referenced | |
| | Digital | |
| | Credential | |
| | supports them, in | |
| | accordance with | |
| | the relevant | |
| | standards. | |
+------------------------------+--------------------+---------------+
Table 7
11. Interoperability of Issuers Supporting Status Assertions
This section outlines how Issuers support Status Assertions,
detailing the necessary metadata and practices to integrate into
their systems.
11.1. Issuer Metadata
Issuers using Status Assertions MUST include in their metadata the
following values:
* status_assertion_endpoint. REQUIRED. It MUST be an HTTPs URL
indicating the endpoint where the Wallet Instances can request
Status Assertions.
Marco, et al. Expires 23 June 2025 [Page 19]
Internet-Draft OAuth Status Assertions December 2024
* credential_hash_alg_supported. REQUIRED. The supported algorithm
used by the Wallet Instance to hash the Digital Credential's
Issuer signed part for which the Status Assertion is requested,
using one of the hash algorithms listed in the [IANA-HASH-REG].
* credential_status_detail_supported. OPTIONAL. JSON array that
outlines the details of each Digital Credential's validity status
supported by the Credential Issuer. This metadata MAY be used to
extend the values defined in Section Status Assertion
(Section 10). Each entry MUST contain the following values:
- credential_status_validity. Numerical value indicating the
validity of the Digital Credential.
- state. String value of a Digital Credential status supported.
- description. String containing the human-readable description
of the status related to this object.
11.2. Issued Digital Credentials
The Issuers that uses the Status Assertions SHOULD include in the
issued Digital Credentials the object status with the JSON member
status_assertion set to a JSON Object containing the following
member:
* credential_hash_alg. REQUIRED. The algorithm used of hashing the
Digital Credential's Issuer signed part to which the Status
Assertion is bound, using one of the hash algorithms listed in the
[IANA-HASH-REG]. Among the hash algorithms, sha-256 is
recommended and SHOULD be implemented by all systems.
The non-normative example of an unsecured payload of an [SD-JWT.VC]
is shown below.
Marco, et al. Expires 23 June 2025 [Page 20]
Internet-Draft OAuth Status Assertions December 2024
{
"vct": "https://credentials.example.com/identity_credential",
"given_name": "John",
"family_name": "Doe",
"email": "johndoe@example.com",
"phone_number": "+1-202-555-0101",
"address": {
"street_address": "123 Main St",
"locality": "Anytown",
"region": "Anystate",
"country": "US"
},
"birthdate": "1940-01-01",
"is_over_18": true,
"is_over_21": true,
"is_over_65": true,
"status": {
"status_assertion": {
"credential_hash_alg": "sha-256",
}
}
}
11.2.1. Issuer Implementation Considerations
When the Digital Credential is issued, the Issuer should calculate
the hash value of the Digital Credential's Issuer signed part using
the algorithm specified in
status.status_assertion.credential_hash_alg and store this
information in its database. This practice enhances efficiency by
allowing the Issuer to quickly compare the requested credential_hash
with the pre-calculated one, when processing Status Assertion
requests made by Holders.
12. Presenting Status Assertions
The Wallet Instance that provides the Status Assertions using
[OpenID4VP], SHOULD include in the vp_token JSON array, as defined in
[OpenID4VP], the Status Assertion along with the related Digital
Credential.
The Verifier that receives a Digital Credential supporting the Status
Assertion, SHOULD:
* Decode and validate the Digital Credential;
* Check the presence of status.status_assertion in the Digital
Credential. If true, the Verifier SHOULD:
Marco, et al. Expires 23 June 2025 [Page 21]
Internet-Draft OAuth Status Assertions December 2024
- produce the hash of the Digital Credential's Issuer signed part
using the hashing algorithm configured in
status.status_assertion.credential_hash_alg;
- decode all the Status Assertions provided in the presentation,
by matching the JWS Header parameter typ set to status-
assertion+jwt and looking for the credential_hash value that
matches with the hash produced at the previous point;
- evaluate the validity of the Status Assertion within the
vp_token parameter, by checking the following items:
o the Issuer claim value MUST match the one in the Digital
Credential;
o the Issued at time claim value MUST be equal to or later
than the Issued at time claim value in the Digital
Credential;
o the Expiration time claim value MUST be later than the
current time;
o the Not before time claim value, if present, MUST be less
than or equal to the current time;
o the confirmation method MUST be used for the validation (eg:
if it uses cryptographic material, this material must be
used for the signature validation);
o the hash of the Digital Credential MUST be produced as
described in Section 7 (Section 7) and MUST match the hash
contained in the Status Assertion.
13. Considerations on Revocation Verification
The recommendation for Verifiers to check the revocation status of
Digital Credentials as a 'SHOULD' instead of a 'MUST' acknowledges
that the decision to verify revocation is not absolute and may be
influenced by various factors. Consider as an example the case of
age-over x; even if it has expired, it may still perform its intended
purpose. As a result, the expiration status alone does not render it
invalid. The adaptability recognizes that the need to verify
revocation status may not always coincide with the actual usability
of a Digital Credential, allowing Verifiers to examine and make
educated conclusions based on a variety of scenarios.
Marco, et al. Expires 23 June 2025 [Page 22]
Internet-Draft OAuth Status Assertions December 2024
14. Detailed Status Assertions
Status Assertions can introduce a more accurate level of detail about
the Digital Credential status. This enables Verifier policies to be
conditioned on the presence of authorative information. This section
proposes syntax to support detailed assertions. The
credential_status_validity claim MUST be present. The
credential_status_detail claim MAY be present and if present MUST be
an object. The semantics of the claims within the
credential_status_detail object are determined by the Issuer.
An example of an enumeration detail status is:
{
"alg": "ES256",
"typ": "status-assertion+jwt",
"kid": "w8ZOZRcx21Zpry7H-0VLBsH7Wf7WXb6TeK3qVMCpY44"
}
.
{
"iss": "https://issuer.example.org",
"iat": 1504699136,
"exp": 1504785536,
"credential_hash": "xnlAq6Ma8fgu1z4hdGphJnKLulaVHpLCFeZFUGpQ2dA",
"credential_hash_alg": "sha-256",
"credential_status_validity": 3,
"credential_status_detail": {
...
},
"cnf": {
"jwk": {
"alg": "ES256",
"kty": "EC",
"crv": "P-256",
"x": "_2ySUmWFjwmraNlo15r6dIBXerVdy_NpJuwAKJMFdoc",
"y": "MV3C88MhhEMba6oyMBWuGeB3dKHP4YADJmGyJwwILsk"
}
}
}
An example of dynamic status using a small matrix for detail status:
Marco, et al. Expires 23 June 2025 [Page 23]
Internet-Draft OAuth Status Assertions December 2024
{
"alg": "ES256",
"typ": "status-assertion+jwt",
"kid": "w8ZOZRcx21Zpry7H-0VLBsH7Wf7WXb6TeK3qVMCpY44"
}
.
{
"iss": "https://issuer.example.org",
"iat": 1504699136,
"exp": 1504785536,
"credential_hash": "xnlAq6Ma8fgu1z4hdGphJnKLulaVHpLCFeZFUGpQ2dA",
"credential_hash_alg": "sha-256",
"credential_status_validity": 0,
"credential_status_detail": {
"preferences": [[1, 0.25, 0.76 ...] ...]
},
"cnf": {
"jwk": {
"alg": "ES256",
"kty": "EC",
"crv": "P-256",
"x": "_2ySUmWFjwmraNlo15r6dIBXerVdy_NpJuwAKJMFdoc",
"y": "MV3C88MhhEMba6oyMBWuGeB3dKHP4YADJmGyJwwILsk"
}
}
}
An example of multiple assertions:
HTTP/1.1 200 Created
Content-Type: application/json
{
"status_assertion_responses": [
$JWT_1, // valid, boolean assertion
$JWT_2, // alg = none, suspended indicator
$JWT_3, // Preferences matrix assertion
]
}
15. Security Considerations
TODO Security
Marco, et al. Expires 23 June 2025 [Page 24]
Internet-Draft OAuth Status Assertions December 2024
16. Privacy Considerations
In the design and implementation of Status Assertions, particular
attention has been paid to privacy considerations to ensure that the
system is respectful of user privacy and compliant with relevant
regulations.
16.1. Privacy Consideration: Status Assertion Request Opacity
The request for a Status Assertion does not transmit the Digital
Credential for which the status is being attested. Instead, it
includes a proof of possession (PoP) of the Digital Credential that
is only interpretable by the Issuer who issued the Digital Credential
for which the Status Assertion is requested. This PoP can be
achieved through a cryptographic signature using the public key
contained within the Digital Credential over the request. This
method is essential for preventing the potential for fraudulent
requests intended to mislead or disclose sensitive information to
unintended parties. By separating the Digital Credential from the
Status Assertion Request, the system ensures that the request does
not inadvertently disclose any information about the Digital
Credential or its Holder. This strategy significantly enhances the
privacy and security of the system by preventing the assertion
process from being used to collect information about Digital
Credentials or their Holders through deceptive requests.
16.2. Privacy Consideration: Opacity of Status Assertion Content
An important privacy consideration is how the Status Assertion is
structured to ensure it does not reveal any information about the
User or the Holder of the Digital Credential. The Status Assertion
is crafted to prove only the vital information needed to verify the
current state of a Digital Credential, moving beyond simple
revocation or suspension checks. This is done by focusing the
assertion content on the Digital Credential's present condition and
the method for its verification, rather than on the identity of the
Digital Credential's Holder. This approach is key in keeping the
User's anonymity intact, making sure that the Status Assertion can be
applied in various verification situations without risking the
privacy of the people involved.
Marco, et al. Expires 23 June 2025 [Page 25]
Internet-Draft OAuth Status Assertions December 2024
16.3. Unlinkability and Reusability of Status Assertions
Status Assertions are designed to uphold privacy by allowing
Verifiers to operate independently, without the need for interaction
or information disclosure to third-party entities or other Verifiers.
This design is pivotal in ensuring unlinkability between Verifiers,
where actions taken by one Verifier cannot be correlated or linked to
actions taken by another. Verifiers can directly validate the status
of a Digital Credential through the Status Assertion, eliminating the
need for external communication. This mechanism is key in protecting
the privacy of individuals whose Digital Credentials are being
verified, as it significantly reduces the risk of tracking or
profiling based on verification activities across various services.
While Status Assertions facilitate unlinkability, they are not
inherently "single use." The specification accommodates the batch
issuance of multiple Status Assertions, which can be single-use.
However, particularly for offline interactions, a Single Assertion
may be utilized by numerous Verifiers. This flexibility ensures that
Status Assertions can support a wide range of verification scenarios,
from one-time validations to repeated checks by different entities,
without compromising the privacy or security of the Digital
Credential Holder.
16.4. Untrackability by Digital Credential Issuers and the "Phone Home"
Problem
A fundamental aspect of the privacy-preserving attributes of Status
Assertions is their ability to address the "phone home" problem,
which is the prevention of tracking by Digital Credential Issuers.
Traditional models often require Verifiers to query a central status
list or contact the Issuer directly, a process that can inadvertently
allow Issuers to track when and where a Digital Credential is
verified. Status Assertions, however, encapsulate all necessary
verification information within the assertion itself. This design
choice ensures that Issuers are unable to monitor the verification
activities of their issued Digital Credentials, thereby significantly
enhancing the privacy of the Holder. By removing the need for real-
time communication with the Issuer for status checks, Status
Assertions effectively prevent the Issuer from tracking verification
activities, further reinforcing the system's dedication to protecting
User privacy.
Marco, et al. Expires 23 June 2025 [Page 26]
Internet-Draft OAuth Status Assertions December 2024
16.5. Minimization of Data Exposure
The Status Assertions are designed around the data minimization
principle. Data minimization ensures that only the necessary
information required for the scope of attesting the non revocation
status of the Digital Credential. This minimizes the exposure of
potentially sensitive data.
16.6. Resistance to Enumeration Attacks
The design of Status Assertions incorporates measures to resist
enumeration attacks, where an adversary attempts to gather
information by systematically verifying different combinations of
data. By implementing robust cryptographic techniques and limiting
the information contained in Status Assertions, the system reduces
the feasibility of such attacks. This consideration is vital for
safeguarding the privacy of the Holders and for ensuring the
integrity of the verification process.
Status Assertions are based on a privacy-by-design approach,
reflecting a deliberate effort to balance security and privacy needs
in the Digital Credential ecosystem.
16.7. Validity Reasons
Depending by the scopes of how the detailed Status Assertions are
implemented, these may disclose details about the Holder or subject
that were not initially committed to during the original Digital
Credential issuance. This can potentially expose additional
information that was not part of the original credentialing process.
Providing a reason that a Digital Credential is no longer valid can
be essential to certain use cases, and unacceptable for others. For
example, in a healthcare setting, a patient should not have medical
reasons for a suspended Digital Credential disclosed in assertions of
suspension. However, in a supply chain context, a product suspension
might benefit from additional information, such as batch or lot
information.
17. IANA Considerations
17.1. JSON Web Token Claims Registration
This specification requests registration of the following Claims in
the IANA "JSON Web Token Claims" registry [IANA.JWT] established by
[RFC7519].
* Claim Name: credential_hash
Marco, et al. Expires 23 June 2025 [Page 27]
Internet-Draft OAuth Status Assertions December 2024
* Claim Description: Hash value of the Digital Credential's Issuer
signed part the Status Assertion is bound to.
* Change Controller: IETF
* Specification Document(s): this specification (Section 10)
* Claim Name: credential_hash_alg
* Claim Description: The Algorithm used of hashing the Digital
Credential's Issuer signed part to which the Status Assertion is
bound.
* Change Controller: IETF
* Specification Document(s): this specification (Section 10)
* Claim Name: credential_status_detail
* Claim Description: New status information provided by the Issuer.
* Change Controller: IETF
* Specification Document(s): this specification (Section 10)
17.2. Media Type Registration
This section requests registration of the following media types
[RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the
manner described in [RFC6838].
To indicate that the content is a JWT-based Status Assertion:
* Type name: application
* Subtype name: status-assertion-request+jwt
* Required parameters: n/a
* Optional parameters: n/a
Marco, et al. Expires 23 June 2025 [Page 28]
Internet-Draft OAuth Status Assertions December 2024
* Encoding considerations: binary; A JWT-based Status Assertion
Request object is a JWT; JWT values are encoded as a series of
base64url-encoded values (some of which may be the empty string)
separated by period ('.') characters.
* Security considerations: See (#Security) of this specification
(Section 15)
* Interoperability considerations: n/a
* Published specification: this specification
* Applications that use this media type: Applications using this
specification for requesting Status Assertions.
* Fragment identifier considerations: n/a
* Additional information:
- File extension(s): n/a
- Macintosh file type code(s): n/a
* Person & email address to contact for further information:
Giuseppe De Marco, gi.demarco@innovazione.gov.it
* Intended usage: COMMON
* Restrictions on usage: none
* Author: Giuseppe De Marco, gi.demarco@innovazione.gov.it
* Change controller: IETF
* Provisional registration? No
To indicate that the content is a CWT-based Status Assertion Request:
* Type name: application
* Subtype name: status-assertion-request+cwt
* Required parameters: n/a
* Optional parameters: n/a
* Encoding considerations: binary
Marco, et al. Expires 23 June 2025 [Page 29]
Internet-Draft OAuth Status Assertions December 2024
* Security considerations: See (#Security) of this specification
(Section 15)
* Interoperability considerations: n/a
* Published specification: this specification
* Applications that use this media type: Applications using this
specification for requesting Status Assertions.
* Fragment identifier considerations: n/a
* Additional information:
- File extension(s): n/a
- Macintosh file type code(s): n/a
* Person & email address to contact for further information:
Giuseppe De Marco, gi.demarco@innovazione.gov.it
* Intended usage: COMMON
* Restrictions on usage: none
* Author: Giuseppe De Marco, gi.demarco@innovazione.gov.it
* Change controller: IETF
* Provisional registration? No
To indicate that the content is a JWT-based Status Assertion:
* Type name: application
* Subtype name: status-assertion+jwt
* Required parameters: n/a
* Optional parameters: n/a
* Encoding considerations: binary
* Security considerations: See (#Security) of this specification
(Section 15)
* Interoperability considerations: n/a
Marco, et al. Expires 23 June 2025 [Page 30]
Internet-Draft OAuth Status Assertions December 2024
* Published specification: this specification
* Applications that use this media type: Applications using this
specification for issuing or presenting Status Assertions.
* Fragment identifier considerations: n/a
* Additional information:
- File extension(s): n/a
- Macintosh file type code(s): n/a
* Person & email address to contact for further information:
Giuseppe De Marco, gi.demarco@innovazione.gov.it
* Intended usage: COMMON
* Restrictions on usage: none
* Author: Giuseppe De Marco, gi.demarco@innovazione.gov.it
* Change controller: IETF
* Provisional registration? No
To indicate that the content is a CWT-based Status Assertion:
* Type name: application
* Subtype name: status-assertion+cwt
* Required parameters: n/a
* Optional parameters: n/a
* Encoding considerations: binary
* Security considerations: See (#Security) of this specification
(Section 15)
* Interoperability considerations: n/a
* Published specification: this specification
* Applications that use this media type: Applications using this
specification for issuing or presenting Status Assertions.
Marco, et al. Expires 23 June 2025 [Page 31]
Internet-Draft OAuth Status Assertions December 2024
* Fragment identifier considerations: n/a
* Additional information:
- File extension(s): n/a
- Macintosh file type code(s): n/a
* Person & email address to contact for further information:
Giuseppe De Marco, gi.demarco@innovazione.gov.it
* Intended usage: COMMON
* Restrictions on usage: none
* Author: Giuseppe De Marco, gi.demarco@innovazione.gov.it
* Change controller: IETF
* Provisional registration? No
To indicate that the content is a JWT-based Status Assertion Error:
* Type name: application
* Subtype name: status-assertion-error+jwt
* Required parameters: n/a
* Optional parameters: n/a
* Encoding considerations: binary
* Security considerations: See (#Security) of this specification
(Section 15)
* Interoperability considerations: n/a
* Published specification: this specification
* Applications that use this media type: Applications using this
specification for issuing Status Assertions Request Errors.
* Fragment identifier considerations: n/a
* Additional information:
- File extension(s): n/a
Marco, et al. Expires 23 June 2025 [Page 32]
Internet-Draft OAuth Status Assertions December 2024
- Macintosh file type code(s): n/a
* Person & email address to contact for further information:
Giuseppe De Marco, gi.demarco@innovazione.gov.it
* Intended usage: COMMON
* Restrictions on usage: none
* Author: Giuseppe De Marco, gi.demarco@innovazione.gov.it
* Change controller: IETF
* Provisional registration? No
To indicate that the content is a CWT-based Status Assertion Error:
* Type name: application
* Subtype name: status-assertion-error+cwt
* Required parameters: n/a
* Optional parameters: n/a
* Encoding considerations: binary
* Security considerations: See (#Security) of this specification
(Section 15)
* Interoperability considerations: n/a
* Published specification: this specification
* Applications that use this media type: Applications using this
specification for issuing Status Assertions Request Errors.
* Fragment identifier considerations: n/a
* Additional information:
- File extension(s): n/a
- Macintosh file type code(s): n/a
* Person & email address to contact for further information:
Giuseppe De Marco, gi.demarco@innovazione.gov.it
Marco, et al. Expires 23 June 2025 [Page 33]
Internet-Draft OAuth Status Assertions December 2024
* Intended usage: COMMON
* Restrictions on usage: none
* Author: Giuseppe De Marco, gi.demarco@innovazione.gov.it
* Change controller: IETF
* Provisional registration? No
18. References
18.1. Normative References
[IANA-HASH-REG]
"IANA - Named Information Hash Algorithm Registry", n.d.,
<https://www.iana.org/assignments/named-information/named-
information.xhtml#hash-alg>.
[IANA.CWT] IANA, "CBOR Web Token (CWT) Claims", n.d.,
<https://www.iana.org/assignments/cwt/cwt.xhtml>.
[IANA.JOSE]
IANA, "JSON Object Signing and Encryption (JOSE)", n.d.,
<https://www.iana.org/assignments/jose/jose.xhtml>.
[IANA.JWT] IANA, "JSON Web Token Claims", n.d.,
<https://www.iana.org/assignments/jwt/jwt.xhtml>.
[IANA.MediaTypes]
IANA, "Media Types", n.d.,
<https://www.iana.org/assignments/media-types/media-
types.xhtml>.
[OpenID.Core]
IANA, "Media Types", n.d.,
<https://www.iana.org/assignments/media-types/media-
types.xhtml>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/rfc/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Marco, et al. Expires 23 June 2025 [Page 34]
Internet-Draft OAuth Status Assertions December 2024
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[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/rfc/rfc6838>.
[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/rfc/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/rfc/rfc7516>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
[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/rfc/rfc7519>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/rfc/rfc7800>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/rfc/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/rfc/rfc8747>.
Marco, et al. Expires 23 June 2025 [Page 35]
Internet-Draft OAuth Status Assertions December 2024
[RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
RFC 9126, DOI 10.17487/RFC9126, September 2021,
<https://www.rfc-editor.org/rfc/rfc9126>.
[RFC9596] Jones, M.B. and O. Steele, "CBOR Object Signing and
Encryption (COSE) "typ" (type) Header Parameter",
RFC 9596, DOI 10.17487/RFC9596, June 2024,
<https://www.rfc-editor.org/rfc/rfc9596>.
18.2. Informative References
[draft-ietf-oauth-status-list]
"draft-ietf-oauth-status-list", n.d.,
<https://datatracker.ietf.org/doc/draft-ietf-oauth-status-
list>.
[ECHR-ART8]
"Article 8 of the European Convention on Human Rights",
n.d.,
<https://www.echr.coe.int/documents/convention_eng.pdf>.
[GDPR] "GDPR", n.d., <https://gdpr-info.eu/>.
[ISO.mdoc] ISO/IEC JTC 1/SC 17, "ISO/IEC 18013-5:2021 ISO-compliant
driving licence", n.d..
[OpenID4VP]
OpenID Foundation, "OpenID for Verifiable Credential
Presentation", n.d., <https://openid.net/specs/openid-4-
verifiable-presentations-1_0.html>.
[RFC6066] "Transport Layer Security (TLS) Extensions: Extension
Definitions", n.d.,
<https://datatracker.ietf.org/doc/html/rfc6066>.
[SD-JWT.VC]
"SD-JWT-based Verifiable Credentials (SD-JWT VC)", n.d.,
<https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-
vc-05.html>.
Appendix A. Acknowledgments
We would like to thank:
* Paul Bastien
* Sara Casanova
Marco, et al. Expires 23 June 2025 [Page 36]
Internet-Draft OAuth Status Assertions December 2024
* Emanuele De Cupis
* Riccardo Iaconelli
* Marina Adomeit
* Victor Näslund
* Giada Sciarretta
* Amir Sharif
* Oliver Terbu
Appendix B. Document History
-03
* Terminology aligned with IETF Token Status Lists
* Marina Adomeit added as co-author
* Added informative references about national and international
regulations
* Abandoned boolean values for Integers values
* Status values aligned with IETF Token Status Lists
* Added the requirement about not specificing audiences in the
Status Assertions
-02
* Removed several comparisons with OAuth Status List
* Status Assertion Request and Response is now a json array with
multiple entries.
* Better generalization about the confirmation methods.
* Removed any informative comparison with OAuth Status List.
* JWT and CWT typ.
* Name of the draft changed from OAuth Status Attestations to OAuth
Status Assertions.
Marco, et al. Expires 23 June 2025 [Page 37]
Internet-Draft OAuth Status Assertions December 2024
* Extended Status Assertion errors table added in the section Status
Error (Section 9).
Authors' Addresses
Giuseppe De Marco
Dipartimento per la trasformazione digitale
Email: gi.demarco@innovazione.gov.it
Orie Steele
Transmute
Email: orie@transmute.industries
Francesco Marino
Istituto Poligrafico e Zecca dello Stato
Email: fa.marino@ipzs.it
Marina Adomeit
SUNET
Email: marina@sunet.se
Marco, et al. Expires 23 June 2025 [Page 38]