2025-09-15 OAuth WG Interim

• Interim meetings for the next 4 weeks

OAuth Client Registration

presented by Pieter Kasselman

• There were several proposals in Madrid around client registration.
  Different drafts are coming at the problem from different ways.
• Why automated client registration? We can get rid of client secrets
  at scale -- SPIFFE + OAuth = no secrets
• What options exist today? manual registration and automated
  registration (RFC7591), but not widely adopted
• Several proposals at IETF 123 - Client ID Metadata, Pushed Client
  Registration, Register on First Use, SPIFFE + DCR
• Enterprises are issuing credentials to individual workloads, these
  workloads need to interact with OAuth servers

Brian: you mentioned client credentials and 7523 don't use client ID,
but they do. The authorization grant of 7523 can be used without client
ID but it does for client authentication.

Pieter: I may have misremembered.

Brian: In general, client credentials is a grant type that leverages
whatever client authentication is used.

• Background on SPIFFE. Bootstrap credentials without secrets.
  Short-lived credentials that expire.
• Get authorization servers out of the business of managing client
  identities.
• Proposal 1: Register on First Use. No additional registration step,
  works with x509 or JWT authentication.
• Implementation example: Signicat SWIM

Rifaat: slide 17 - step A is a one-time thing, is this per domain?

Pieter: SPIFFE can support multiple trust domains.

Brian: In step C, is that the authorization request or is that the token
request?

Pieter: There are two flows described in the document. This picture is
about the client credentials flow, not for the redirect URI flow.

Brian: In that context this would be the token request.

• Proposal 2: DCR with Trusted Issuer Credentials
• Other options: RFC7523

Christian: Are these credentials a verifiable statement about the client
or are they bound to a client?

Pieter: Both ways exist today. There is work in WIMSE with
workload-to-workload introducing Workload Identity Token which has a
bound key. This will be incorporated into the SPIFFE specifications.

Christian: Once you have something that is key bound the key becomes an
implicit client ID.

Pieter: In your cases, is the key a long lived key or constantly
rotating?

Christian: Long lived and we are using it as a replacement for client
ID.

Karl: Many cases need a long lived stable identifier but also need to
rotate keys. How do you address that if you are using key identifiers as
client instance identifier?

Pieter: In SPIFFE the instance identity is always the same. An
identifier is assigned, the key is short lived. The proposal here is to
use the SPIFFE identifier rather than the key identifier.

Christian: We have clients that are not long lived and the key lasts as
long as the client lives. Typically a few months.

Deb: as long as there is a mapping somewhere of the real ID to the key
value

• What next?
• Explore converging with Client ID Metadata draft

Fin