Identity Deep Dive

OAuth SPIFFE Client Authentication

Profiles RFC 7521, RFC 7523 and attestation-based client authentication so an OAuth client can authenticate with a SPIFFE SVID (JWT, WIT or X.509) instead of a client secret.

Where it stands
Status unknown
Official text
Documented support
0
Activity
1 signals in 90 days

No explainer written for this spec yet. The summary, relations and documented support below are maintained.

Profiles RFC 7521, RFC 7523 and attestation-based client authentication so an OAuth client can authenticate with a SPIFFE SVID (JWT, WIT or X.509) instead of a client secret.

How it relates to other specs

Relations diagram
flowchart LR
  s_spiffe_client_auth["OAuth SPIFFE Client Authentication"]
  s_spiffe["SPIFFE"]
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  s_attestation_client_auth["Attestation-Based Client Authentication"]
  style s_spiffe_client_auth stroke-width:3px
  s_spiffe_client_auth -->|Builds on| s_spiffe
  s_spiffe_client_auth -->|Profiles| s_jwt_bearer
  s_spiffe_client_auth -->|Profiles| s_attestation_client_auth

Documented support

Adoption lists only support stated in official documentation (the vendor's or project's own, or a standards body's page naming it), and a weekly check confirms the cited phrase is still on that page. Experimental, alpha and beta support is counted separately as preview.

No sourced support entries collected yet. This says nothing about how widely it is used.

Activity

Revisions from the Datatracker, explanations from this site's daily runs, and mailing-list subjects naming the draft.

Explanations on this site

  • DiscussionIETF WIMSE

    AIMS cross-domain gap text: agreed to add bounding sentences that issuer trust does not decide authorization and that determinations expire.

    AIMS -01: upstream authorities for Workload Identity Certificates (trust between trust domains) (6 new messages)

    Read the explanation

    The thread continues David Croston's proposal to record in AIMS a gap about trust between trust domains, with a mechanism-neutral property list (verifier trusts another domain's issuer without bilateral setup, issuer speaks only for its names, verifier chooses domains, bounded withdrawal). Jiahui Miao adds a bounding property: accepting another domain's issuer does not by itself establish authorization for an action. ShaoBao Li adds a time half, that a determination holds at the time of observation and not after the evidence expires. Cliff agrees to put one sentence in the gap text and the rest, including recording "not determined" rather than "not permitted", in Section 10.4. Sriram Shankarlingam agrees and notes his DNS-link link token grants nothing. Several messages cite the authors' own drafts and conformance suites.

    • Federating agents across organizations where no bilateral trust bundle exchange exists.
    • Auditors needing to tell apart refused because authority could not be determined and refused because the operation is not permitted.
    • Related in OAuth WG: draft-ietf-oauth-spiffe-client-auth. Related only loosely (workload identity to OAuth client binding); the material does not cite it.