Skip to main content

OAuth Status Assertions
draft-demarco-oauth-status-assertions-00

Document Type Active Internet-Draft (individual)
Authors Giuseppe De Marco , Orie Steele , Francesco Marino
Last updated 2024-06-10
Replaces draft-demarco-oauth-status-attestations, draft-demarco-status-attestations
RFC stream (None)
Intended RFC status (None)
Formats
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-00
Network Working Group                                        G. D. Marco
Internet-Draft               Dipartimento per la trasformazione digitale
Intended status: Informational                                 O. Steele
Expires: 12 December 2024                                      Transmute
                                                               F. Marino
                                Istituto Poligrafico e Zecca dello Stato
                                                            10 June 2024

                        OAuth Status Assertions
                draft-demarco-oauth-status-assertions-00

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 verifier along with the
   corresponding digital credentials.  The approach outlined in this
   document makes the verifier able to check 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-status-assertions/draft-
   demarco-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-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 12 December 2024                [Page 1]
Internet-Draft           OAuth Status Assertions               June 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 12 December 2024.

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 Credential . . . . . . . . . . . . .   6
   7.  Status Assertion Request  . . . . . . . . . . . . . . . . . .   6
   8.  Status Assertion Response . . . . . . . . . . . . . . . . . .  11
   9.  Status Assertion Error  . . . . . . . . . . . . . . . . . . .  12
     9.1.  Rationale About The Unsigned Status Assertion Errors  . .  15
   10. Status Assertion  . . . . . . . . . . . . . . . . . . . . . .  16
   11. Interoperability of Credential Issuers Supporting Status
           Assertions  . . . . . . . . . . . . . . . . . . . . . . .  19
     11.1.  Credential Issuer Metadata . . . . . . . . . . . . . . .  19
     11.2.  Issued Digital Credentials . . . . . . . . . . . . . . .  20
       11.2.1.  Credential Issuer Implementation Considerations  . .  21
   12. Presenting Status Assertions  . . . . . . . . . . . . . . . .  21
   13. Considerations On Revocation Verification . . . . . . . . . .  22
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  22
   15. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  22
     15.1.  Privacy Consideration: Status Assertion Request
            Opacity  . . . . . . . . . . . . . . . . . . . . . . . .  22
     15.2.  Privacy Consideration: Opacity of Status Assertion
            Content  . . . . . . . . . . . . . . . . . . . . . . . .  23
     15.3.  Unlinkability and Reusability of Status Assertions . . .  23

Marco, et al.           Expires 12 December 2024                [Page 2]
Internet-Draft           OAuth Status Assertions               June 2024

     15.4.  Untrackability by Digital Credential Issuers and the
            "Phone Home" Problem . . . . . . . . . . . . . . . . . .  24
     15.5.  Minimization of Data Exposure  . . . . . . . . . . . . .  24
     15.6.  Resistance to Enumeration Attacks  . . . . . . . . . . .  24
   16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
     16.1.  JSON Web Token Claims Registration . . . . . . . . . . .  25
     16.2.  Media Type Registration  . . . . . . . . . . . . . . . .  26
   17. Normative References  . . . . . . . . . . . . . . . . . . . .  31
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  32
   Appendix B.  Document History . . . . . . . . . . . . . . . . . .  33
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33

1.  Introduction

   Status Assertions ensure the non-revocation of digital credentials,
   whether in JSON Web Tokens (JWT) or CBOR Web Tokens (CWT) format.
   Status Assertions function similarly to OCSP Stapling, allowing
   clients to present to the relying parties time-stamped assertions
   provided by the credential issuer.  The approach outlined in this
   specification enables the verification of 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 client, such as a
   Wallet Instance, requests and obtains a Status Assertion from the
   credential issuer.

  +-----------------+                              +-------------------+
  |                 | Requests Status Assertions   |                   |
  |                 |----------------------------->|                   |
  | Client          |                              | Credential Issuer |
  |                 | Status Assertions            |                   |
  |                 |<-----------------------------|                   |
  +-----------------+                              +-------------------+

   *Figure 1*: Status Assertion Issuance Flow.

   The figure below illustrates the process by which a client presents
   the Status Assertion along with the corresponding digital credential,
   to prove the non-revocation status of the digital credential to a
   verifier.

   +-- ----------------+                             +----------+
   |                   | Presents Digital Credential |          |
   | Client            | and Status Assertion        | Verifier |
   |                   |---------------------------->|          |
   +-------------------+                             +----------+

Marco, et al.           Expires 12 December 2024                [Page 3]
Internet-Draft           OAuth Status Assertions               June 2024

   *Figure 2*: Status Assertion Presentation Flow.

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:  An entity that receives Verifiable Credentials and has
      control over them to present them to the Verifiers as Verifiable
      Presentations.

   Digital Credential:  A set of one or more claims about a subject made
      by a Credential Issuer.  Alternative names are "Verifiable
      Credential" or "Credential".

   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.

   Holder:  An entity that receives Verifiable Credentials and has
      control over them to present them to the Verifiers as Verifiable
      Presentations.

   Verifier:  Entity that relies on the validity of the Digital
      Credentials presented to it.  This Entity, also known as a Relying
      Party, verifies the authenticity and validity of the Digital
      Credentials, including their revocation status, before accepting
      them.

   Wallet Instance:  The digital Wallet in control of a User, also known
      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.

Marco, et al.           Expires 12 December 2024                [Page 4]
Internet-Draft           OAuth Status Assertions               June 2024

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 (https://datatracker.ietf.org/doc/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 Article 8 of the European Convention on Human Rights
   (https://www.echr.coe.int/documents/convention_eng.pdf) and in the
   the European Union's General Data Protection Regulation (GDPR
   (https://gdpr-info.eu/)), 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:

   *  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 both the Status
      Assertion and the Digital Credential it refers MUST NOT be
      considered valid anymore.  The expiration datetime MUST be
      superior to the Status Assertion issuance datetime and it MUST end
      before the expiration datetime of the Digital Credential;

   *  MUST enable the offline use cases by employing validation using a
      cryptographic signature and the cryptographic public key of the
      Credential Issuer.

   *  MUST NOT contain personal information about the User who owns the
      Digital Credential to which the Status Assertion refers.

Marco, et al.           Expires 12 December 2024                [Page 5]
Internet-Draft           OAuth Status Assertions               June 2024

6.  Proof of Possession of a Credential

   The concept of Proof of Possession (PoP) of a Credential within the
   framework of the Status Assertion specification encompasses a broader
   perspective than merely possessing the digital bytes of the
   Credential.  It involves demonstrating rightful control or ownership
   over the 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 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 Credential, using the
       Credential's cnf parameter.

   The essence of requiring proof of possession over the Credential
   through the confirmation method, such has proving the control of the
   cryptographic material related to a Credential, is to ensure that the
   entity in possession of the Credential can execute actions
   exclusively reserved to the legitimate Holder.  The dual-layered
   approach of requiring both possession of the 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 Credential was
   originally issued, affirming the authenticity and rightful possession
   of the Credential.

7.  Status Assertion Request

   The Credential Issuer provides the Wallet Instance with a Status
   Assertion, which is bound to a Digital Credential.  This allows the
   Wallet Instance to present it, along with the Digital Credential
   itself, to a Verifier as proof of the Digital Credential's non-
   revocation status.

   The following diagram shows the Wallet Instance requesting a Status
   Assertion to a Credential Issuer, related to a specific Credential
   issued by the same Credential Issuer.

Marco, et al.           Expires 12 December 2024                [Page 6]
Internet-Draft           OAuth Status Assertions               June 2024

+-------------------+                                  +--------------------+
|                   |                                  |                    |
|  Wallet Instance  |                                  | Credential Issuer  |
|                   |                                  |                    |
+--------+----------+                                  +----------+---------+
         |                                                        |
         | HTTP POST /status                                      |
         |  status_assertion_requests = [$StatusAssertionRequest] |
         +-------------------------------------------------------->
         |                                                        |
         |  Status Assertion Responses [...]                      |
         <--------------------------------------------------------+
         |                                                        |
+--------+----------+                                  +----------+---------+
|                   |                                  |                    |
|  Wallet Instance  |                                  | Credential Issuer  |
|                   |                                  |                    |
+-------------------+                                  +--------------------+

   The Wallet Instance sends the Status Assertion request to the
   Credential Issuer, where: - The request MUST contain the base64url
   encoded hash value of the Digital Credential, 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.

   When the JWT or CWT format are used, the JWT/CWT MUST contain the
   parameters defined in the following table.

Marco, et al.           Expires 12 December 2024                [Page 7]
Internet-Draft           OAuth Status Assertions               June 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.      |           |
    +--------+-------------------------------------------+-----------+
    | *alg*  | A digital signature algorithm identifier  | [RFC7516] |
    |        | such as per IANA "JSON Web Signature and  | Section   |
    |        | Encryption Algorithms" registry.  It MUST | 4.1.1     |
    |        | NOT be set to none or any symmetric       |           |
    |        | algorithm (MAC) identifier.               |           |
    +--------+-------------------------------------------+-----------+
    | *kid*  | It is the Unique identifier of the JWK or | [RFC7515] |
    |        | Cose_Key owned by the Holder and used for |           |
    |        | validating the signature of the Status    |           |
    |        | Assertion Request.  When the Credential   |           |
    |        | confirmation method uses a cryptographic  |           |
    |        | material, it MUST match the one contained |           |
    |        | in the Credential.  The header parameter  |           |
    |        | kid is required when other cryptographic  |           |
    |        | public key identification methods are not |           |
    |        | used, such as x5c.                        |           |
    +--------+-------------------------------------------+-----------+

                                 Table 1

Marco, et al.           Expires 12 December 2024                [Page 8]
Internet-Draft           OAuth Status Assertions               June 2024

   +=======================+==========================+===============+
   | Payload               | Description              | Reference     |
   +=======================+==========================+===============+
   | *iss*                 | Status Assertion Request | [RFC9126],    |
   |                       | Issuer identifier.  The  | [RFC7519]     |
   |                       | value is supposed to be  |               |
   |                       | used for identifying the |               |
   |                       | Wallet that has issued   |               |
   |                       | the request.  It is out  |               |
   |                       | of scope for this        |               |
   |                       | document defining how    |               |
   |                       | this value must be set.  |               |
   +-----------------------+--------------------------+---------------+
   | *aud*                 | It MUST be set with the  | [RFC9126],    |
   |                       | Credential Issuer Status | [RFC7519]     |
   |                       | Assertion endpoint URL   |               |
   |                       | as value that identify   |               |
   |                       | the intended audience.   |               |
   +-----------------------+--------------------------+---------------+
   | *exp*                 | UNIX Timestamp with the  | [RFC9126],    |
   |                       | expiration time of the   | [RFC7519],    |
   |                       | JWT.  It MUST be         | [RFC7515]     |
   |                       | superior to the value    |               |
   |                       | set for iat .            |               |
   +-----------------------+--------------------------+---------------+
   | *iat*                 | UNIX Timestamp with the  | [RFC9126],    |
   |                       | time of JWT/CWT          | [RFC7519]     |
   |                       | issuance.                |               |
   +-----------------------+--------------------------+---------------+
   | *jti*                 | Unique identifier for    | [RFC7519]     |
   |                       | the JWT.                 | Section 4.1.7 |
   +-----------------------+--------------------------+---------------+
   | *credential_hash*     | Hash value of the        | this          |
   |                       | Digital Credential the   | specification |
   |                       | Status Assertion is      |               |
   |                       | bound to.                |               |
   +-----------------------+--------------------------+---------------+
   | *credential_hash_alg* | The Algorithm used of    | this          |
   |                       | hashing the Digital      | specification |
   |                       | Credential to which the  |               |
   |                       | Status Assertion is      |               |
   |                       | bound.  The value SHOULD |               |
   |                       | be set to sha-256.       |               |
   +-----------------------+--------------------------+---------------+

                                 Table 2

Marco, et al.           Expires 12 December 2024                [Page 9]
Internet-Draft           OAuth Status Assertions               June 2024

   Below is a non-normative example of a Status Assertion Request with
   the JWT headers and payload are represented without applying
   signature and encoding:

   {
       "alg": "ES256",
       "typ": "status-assertion-request+jwt",
       "kid": $CREDENTIAL-CNF-JWKID
   }
   .
   {
       "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": $Issuer-Signed-JWT-Hash
       "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 /
       / kid / 4: h'3132' / $CREDENTIAL-CNF-CWKID /
     } >>,
     / 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: $Issuer-Signed-JWT-Hash /,
       / credential_hash_alg / 9: sha-256 /
     } >>,
   ]

   Below a non-normative example representing a Status Assertion Request
   array with a single Status Assertion Reuqest object in JWT format.

Marco, et al.           Expires 12 December 2024               [Page 10]
Internet-Draft           OAuth Status Assertions               June 2024

POST /status HTTP/1.1
Host: issuer.example.org
Content-Type: application/json

{
    "status_assertion_requests" : ["${base64url(json({typ: (some pop for status-assertion)+jwt, ...}))}.payload.signature", ... ]
}

   The Status Assertion HTTP request can be sent to a single Credential
   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 Credential 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 Credential 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 Credential 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:

HTTP/1.1 200 Created
Content-Type: application/json

{
    "status_assertion_responses": ["${base64url(json({typ: status-assertion+jwt, ...}))}.payload.signature", ... ]
}

Marco, et al.           Expires 12 December 2024               [Page 11]
Internet-Draft           OAuth Status Assertions               June 2024

   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]_ produces
   _[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

   If the Status Assertion is requested for a non-existent, expired,
   revoked or invalid Digital Credential, the Credential Issuer MUST
   respond with an HTTP Response with the status code set to 200 and the
   status_assertion_responses array with the related Status Assertion
   Error object.

   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 Credential that has requested the Status Assertion.
   Therefore, it is not necessary that the Status Assertion Error
   contains the parameter aud within its payload.

   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.

Marco, et al.           Expires 12 December 2024               [Page 12]
Internet-Draft           OAuth Status Assertions               June 2024

   {
       "alg": "ES256",
       "typ": "status-assertion-error+jwt",
       "kid": "Issuer-JWK-KID"
   }
   .
   {
       "iss": "https://issuer.example.org",
       "jti": "6f204f7e-e453-4dfd-814e-9d155319408c"
       "credential_hash": $CREDENTIAL-HASH,
       "credential_hash_alg": "sha-256",
       "error": "credential_revoked",
       "error_description": "Credential is revoked."
       }
   }

   The Status Assertion Error object MUST contain the parameters
   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 12 December 2024               [Page 13]
Internet-Draft           OAuth Status Assertions               June 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, such as attribute      |             |
   |                     | changes, revocation reasons,  |             |
   |                     | in relation to the error      |             |
   |                     | value.                        |             |
   +---------------------+-------------------------------+-------------+

                                  Table 4

Marco, et al.           Expires 12 December 2024               [Page 14]
Internet-Draft           OAuth Status Assertions               June 2024

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 parameteralg value to none for Status Assertion Errors
   that do not require signatures.  This approach conserves
   computational resources and prevents abuse, especially in scenarios
   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 Client that received them MUST validate the signature. ##
   Status Assertion Error Values

   The error parameter 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 Parameter Value       | Description          |Reference    |
   +=============================+======================+=============+
   | *credential_revoked*        | The Digital          |this         |
   |                             | Credential results   |specification|
   |                             | as already revoked.  |             |
   |                             | The reason of        |             |
   |                             | revocation MAY be    |             |
   |                             | provided in the      |             |
   |                             | error_description    |             |
   |                             | field.               |             |
   +-----------------------------+----------------------+-------------+
   | *credential_updated*        | One or more          |this         |
   |                             | information          |specification|
   |                             | contained in the     |             |
   |                             | Digital Credential   |             |
   |                             | are changed.  The    |             |
   |                             | error_description    |             |
   |                             | field SHOULD contain |             |
   |                             | a human-readable     |             |
   |                             | text describing the  |             |
   |                             | general parameters   |             |
   |                             | updated without      |             |
   |                             | specifying each one. |             |
   +-----------------------------+----------------------+-------------+
   | *credential_invalid*        | The Digital          |this         |
   |                             | Credential is        |specification|
   |                             | invalid.  The        |             |
   |                             | error_description    |             |

Marco, et al.           Expires 12 December 2024               [Page 15]
Internet-Draft           OAuth Status Assertions               June 2024

   |                             | field SHOULD contain |             |
   |                             | the reason of        |             |
   |                             | invalidation.        |             |
   +-----------------------------+----------------------+-------------+
   | *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 a Credential Issuer, the
   Issuer checks the status of the Digital Credential and creates a
   Status Assertion bound to it.

   If the Digital Credential is valid, the Credential Issuer creates a
   new Status Assertion, which a non-normative example is given below
   where the format is JWT.

Marco, et al.           Expires 12 December 2024               [Page 16]
Internet-Draft           OAuth Status Assertions               June 2024

   {
       "alg": "ES256",
       "typ": "status-assertion+jwt",
       "kid": $ISSUER-JWKID
   }
   .
   {
       "iss": "https://issuer.example.org",
       "iat": 1504699136,
       "exp": 1504785536,
       "credential_hash": $CREDENTIAL-HASH,
       "credential_hash_alg": "sha-256",
       "cnf": {
           "jwk": {...}
       }
   }

   The Status Assertion MUST contain the parameters defined below.

Marco, et al.           Expires 12 December 2024               [Page 17]
Internet-Draft           OAuth Status Assertions               June 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           | [RFC7515]     |
    |           | Credential Issuer JWK.  It is      |               |
    |           | required when x5c or other         |               |
    |           | cryptographic public key           |               |
    |           | resolution identifiers are not     |               |
    |           | used.                              |               |
    +-----------+------------------------------------+---------------+
    | *x5c*     | X.509 certificate chain about the  | [RFC7515]     |
    |           | Credential Issuer.  It is required |               |
    |           | when kid or other parameter are    |               |
    |           | not used.                          |               |
    +-----------+------------------------------------+---------------+

                                 Table 6

   +=======================+==========================+===============+
   | Payload Parameter     | Description              | Reference     |
   | Name                  |                          |               |
   +=======================+==========================+===============+
   | *iss*                 | It MUST be set to the    | [RFC9126],    |
   |                       | identifier of the        | [RFC7519]     |
   |                       | Issuer.                  |               |
   +-----------------------+--------------------------+---------------+
   | *iat*                 | UNIX Timestamp with the  | [RFC9126],    |
   |                       | time of the Status       | [RFC7519]     |
   |                       | Assertion issuance.      |               |
   +-----------------------+--------------------------+---------------+
   | *exp*                 | UNIX Timestamp with the  | [RFC9126],    |
   |                       | expiration time of the   | [RFC7519],    |
   |                       | JWT.  It MUST be greater | [RFC7515]     |

Marco, et al.           Expires 12 December 2024               [Page 18]
Internet-Draft           OAuth Status Assertions               June 2024

   |                       | than the value set for   |               |
   |                       | iat.                     |               |
   +-----------------------+--------------------------+---------------+
   | *credential_hash*     | Hash value of the        | this          |
   |                       | Digital Credential the   | specification |
   |                       | Status Assertion is      |               |
   |                       | bound to.                |               |
   +-----------------------+--------------------------+---------------+
   | *credential_hash_alg* | The Algorithm used of    | this          |
   |                       | hashing the Digital      | specification |
   |                       | Credential to which the  |               |
   |                       | Status Assertion is      |               |
   |                       | bound.  The value SHOULD |               |
   |                       | be set to sha-256.       |               |
   +-----------------------+--------------------------+---------------+
   | *cnf*                 | JSON object containing   | [RFC7800]     |
   |                       | confirmation methods.    | Section 3.1,  |
   |                       | The sub-member contained | [RFC8747]     |
   |                       | within cnf member, such  | Section 3.1   |
   |                       | 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 Credential Issuers Supporting Status Assertions

   This section outlines how Credential Issuers support Status
   Assertions, detailing the necessary metadata and practices to
   integrate into their systems.

11.1.  Credential Issuer Metadata

   The Credential Issuers that uses the Status Assertions MUST include
   in their OpenID4VCI [@!OpenID.VCI] metadata the claims:

Marco, et al.           Expires 12 December 2024               [Page 19]
Internet-Draft           OAuth Status Assertions               June 2024

   *  status_assertion_endpoint.  REQUIRED.  It MUST be an HTTPs URL
      indicating the endpoint where the Wallet Instances can request
      Status Assertions.

   *  credential_hash_alg_supported.  REQUIRED.  The supported Algorithm
      used by the Wallet Instance to hash the Digital Credential for
      which the Status Assertion is requested, using one of the hash
      algorithms listed in the [IANA - Named Information Hash Algorithm
      Registry] (https://www.iana.org/assignments/named-information/
      named-information.xhtml#hash-alg).

11.2.  Issued Digital Credentials

   The Credential 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 to which the Status Assertion is bound, using
      one of the hash algorithms listed in the [IANA - Named Information
      Hash Algorithm Registry] (https://www.iana.org/assignments/named-
      information/named-information.xhtml#hash-alg).  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 12 December 2024               [Page 20]
Internet-Draft           OAuth Status Assertions               June 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.  Credential Issuer Implementation Considerations

   When the Digital Credential is issued, the Credential Issuer SHOULD
   calculate the hash value 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 Credential 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 12 December 2024               [Page 21]
Internet-Draft           OAuth Status Assertions               June 2024

      -  produce the hash of the Digital Credential 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.

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.

14.  Security Considerations

   TODO Security

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

15.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 credential that is only
   interpretable by the Credential 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

Marco, et al.           Expires 12 December 2024               [Page 22]
Internet-Draft           OAuth Status Assertions               June 2024

   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.

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

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

Marco, et al.           Expires 12 December 2024               [Page 23]
Internet-Draft           OAuth Status Assertions               June 2024

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

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

15.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 credential 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.  IANA Considerations

Marco, et al.           Expires 12 December 2024               [Page 24]
Internet-Draft           OAuth Status Assertions               June 2024

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

   *  Claim Description: The Digital Credential format the Status
      Assertion is bound to.

   *  Change Controller: IETF

   *  Specification Document(s): [[ (#digital-credential-proof-of-
      possession) of this specification ]]

   *  Claim Name: credential

   *  Claim Description: The Digital Credential the Status Assertion is
      bound to.

   *  Change Controller: IETF

   *  Specification Document(s): [[ (#digital-credential-proof-of-
      possession) of this specification ]]

   *  Claim Name: credential_hash

   *  Claim Description: Hash value of the Digital Credential the Status
      Assertion is bound to.

   *  Change Controller: IETF

   *  Specification Document(s): [[ (#status-assertion) of this
      specification ]]

   *  Claim Name: credential_hash_alg

   *  Claim Description: The Algorithm used of hashing the Digital
      Credential to which the Status Assertion is bound.

   *  Change Controller: IETF

Marco, et al.           Expires 12 December 2024               [Page 25]
Internet-Draft           OAuth Status Assertions               June 2024

   *  Specification Document(s): [[ (#status-assertion) of this
      specification ]]

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

   *  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
      ]]

   *  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

Marco, et al.           Expires 12 December 2024               [Page 26]
Internet-Draft           OAuth Status Assertions               June 2024

   *  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

   *  Security considerations: See (#Security) of [[ this specification
      ]]

   *  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

Marco, et al.           Expires 12 December 2024               [Page 27]
Internet-Draft           OAuth Status Assertions               June 2024

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

   *  Interoperability considerations: n/a

   *  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

Marco, et al.           Expires 12 December 2024               [Page 28]
Internet-Draft           OAuth Status Assertions               June 2024

   *  Required parameters: n/a

   *  Optional parameters: n/a

   *  Encoding considerations: binary

   *  Security considerations: See (#Security) of [[ this specification
      ]]

   *  Interoperability considerations: n/a

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

Marco, et al.           Expires 12 December 2024               [Page 29]
Internet-Draft           OAuth Status Assertions               June 2024

   *  Security considerations: See (#Security) of [[ this specification
      ]]

   *  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

   *  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
      ]]

   *  Interoperability considerations: n/a

Marco, et al.           Expires 12 December 2024               [Page 30]
Internet-Draft           OAuth Status Assertions               June 2024

   *  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

   *  Intended usage: COMMON

   *  Restrictions on usage: none

   *  Author: Giuseppe De Marco, gi.demarco@innovazione.gov.it

   *  Change controller: IETF

   *  Provisional registration?  No

17.  Normative References

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

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

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

Marco, et al.           Expires 12 December 2024               [Page 31]
Internet-Draft           OAuth Status Assertions               June 2024

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

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

Appendix A.  Acknowledgments

   We would like to thank:

   *  Paul Bastien

   *  Sara Casanova

   *  Emanuele De Cupis

   *  Riccardo Iaconelli

   *  Marina Adomeit

   *  Victor Näslund

   *  Giada Sciarretta

Marco, et al.           Expires 12 December 2024               [Page 32]
Internet-Draft           OAuth Status Assertions               June 2024

   *  Amir Sharif

Appendix B.  Document History

   -00

   *  Removed any comparison 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.

   *  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

Marco, et al.           Expires 12 December 2024               [Page 33]