OAuth Status Assertions

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

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

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

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

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

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

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

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

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

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

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

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

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

• Intended usage: COMMON¶

• Restrictions on usage: none¶

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

• Change controller: IETF¶

• Provisional registration? No¶

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

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

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