Episode 081: 01‐23‐2025 OAuth Status List and Attestation‐Based Client Authentication - GluuFederation/identerati-office-hours GitHub Wiki

Title: OAuth Status List and Attestation-Based Client Authentication

Description

In SAML, the entityID identifier is used for both IDPs and RPs. But in OpenID Connect, there is no stable identifier for the RP. This has become problematic for verifiable credential presentation. One solution is to enable the client to assert their identity, via an attestation. Oversight? Feature? Either way, it's going to be really helpful! We're going to save a few minutes at the end to talk about a new draft OAuth standard for Status Lists, which is like a more efficient "certificate revocation list" design to revoke JWT tokens. Clients should verify not only the signature, but also the status of the token--just like we check for revocation of X.509 certificates.

Homework

Takeaways

  • ⚡ There is no perfect solution for token revocation. Current protocols for X.509 Certificate revocation are inefficient and potentially enable correlation. This new IETF OAuth Staus List draft publishes the status of all JWTs more efficiently than X.509 CRLs without exposing correlatable information.

  • ⚡ JWT Validation is easy for developers using OAuth Status List -- the index value and URL of the OAuth Status list is included in the target JWT. Unlike X.509 CRL metadata, all OAuth Status flag tells you is whether the JWT is revoked.

  • ⚡ Attestation-Based Client Authentication, or "ABC Authentication" for short, is more then just a stable identifier for the RP. In fact, I may have been confusing this with "The Use of Attestation in OAuth 2.0 Dynamic Client Registration", which is an expired IETF draft. ABC Authn is optimal for a one-time interaction, where the use of Dynamic Client Registration for a "one-time-use" client would be overkill.

  • ⚡ ABC Authn is similar in some ways to the attestation that a FIDO authenticator sends--it doesn't contain any claims or data that can be used for correlation. It is used to assert what kind of software this is, for example "a German Gov't Wallet iOS software instance."

  • ⚡ The integrity of the attestation can be enhanced with other attestations -- for example, an attestation from the Google Integrity API, certifying that the wallet software has the same checksum, and that it is installed on a non-rooted phone. In this way, the RP can understand can better understand the risk of trusting the credential asserted.

Livestream Audio Archive

Will be Here