Editorial pass on Introduction + implementor-focused Use Cases appendix

[dickhardt]

This is an editor's integration pass over the use-case material, intended as an alternative resolution to #13. It separates the editorial/copy layer (mine to set as editor) from the open design questions that are still under WG discussion, so we can land the prose without prejudging the unresolved decisions.

What's here

• Tighter Introduction. Adopts the crisper opener from Clarify Use Cases #13 (the OIDC acronym, "in the form of an ID Token", a single-sentence round trip) in the spec's existing active voice. The nonce mechanics and the component-to-component framing from Clarify Use Cases #13 are intentionally left out of the opener — nonce belongs in the flow sections, and the component case is one of the open questions below.
• Restored use-case list in the Introduction (a list this time), pointing to the new appendix.
• New non-normative Use Cases appendix (Appendix A) covering the first-party token exchange, distributed RP components, and peer-to-peer scenarios. Each is written to answer "what does an implementer actually do here," with emphasis on the genuinely non-obvious step — binding the OIDC identity to the application's own channel/identity (e.g. a WebRTC DTLS fingerprint), which @JonasPrimbs identified in the Clarify Use Cases #13 thread.
• End-User terminology adopted consistently per OIDC Core (hyphenated), with a new Terminology entry.

Builds clean locally through both stages (mmark → xml2rfc).

Relationship to #13

This lifts and re-voices the contributions from #13 by @JonasPrimbs — thank you. The intent is to integrate the ready editorial material now and route the still-open items to discussion rather than bake them into the spec via a copy PR:

There was potentially normative suggestions wrt aud and different client_ids; nonce semantics; sub and privacy; and validity periods.

@JonasPrimbs -- please open up issues on these if you think we still need to work through them -- I did not want to conflate those discussions with the editorial changes

Suggest we close #13 in favor of this once the group is comfortable, and take the four items above to the WG / a 1:1.

[JonasPrimbs]

Did I get this one correctly?
A mobile app should request a key-bound ID Token, keep it, and later exchange it at the Authorization Server for an Access Token of the same or a different first-party service.
Sounds nice. I also thought of this, but it gives me flashbacks to Kerberos Golden Tickets.

[EthanHeilman]

Thanks for your review

Isn't this just RFC 8693: OAuth 2.0 Token Exchange or I am misunderstanding you?

OIDC RP - exampleApp (mobile app) and example.com (backend)
OP - Google OpenID Provider
AS - example.com AS for managing authorization to the resources it controls.

Example.com wants SSO, so it enables users to authorize their identities view OIDC. It then uses the ID Token to authorize the user's identity and issue an access token to the mobile app for that identity.

1. Alice wishes to sign exampleApp and clicks sign in with Google,
2. exampleApp redirects Alice to Google OIDC auth page,
3. Alice consents and authenticates to Google, Google communicates Alice's ID Token, refresh Token to exampleApp,
4. exampleApp (authenticating component) presents ID Token to the example.com AS and exchanges the ID Token for an issued access token at example.com

Key binding would tighten the security of this common pattern by enabling the use of HSMs/TPMs/SSMs and DPoP.

[dickhardt]

The mobile app or SPA getting the id token itself is one of the common patterns we are improving with this spec.

@JonasPrimbs sid you have a concern or was that just a general comment?

[JonasPrimbs]

Thanks to @dickhardt for the effort!
It precisely covers the results of our discussion in #13 so far.

The first use case seems new. I cannot remember whether we discussed it in the WG yet. Maybe I just missed the call.
In general, we should not add new content to the draft and call it an "editorial pass".
However, I like that use case, so I approve these changes, but I'm not speaking for the WG.

[EthanHeilman]

The first use case seems new. I cannot remember whether we discussed it in the WG yet. Maybe I just missed the call. In general, we should not add new content to the draft and call it an "editorial pass". However, I like that use case, so I approve these changes, but I'm not speaking for the WG.

I think you are referring to this use case?

a mobile app that exchanges an ID Token, along with a proof of possession, at a first-party authorization service for an access token;

If so that use case exists in the current draft, the editorial changes @dickhardt made changed it to a bullet point, but didn't change the content. This use case has existed since the initial commit from Oct 21, 2025

connect-key-binding/openid-connect-key-binding-1_0.md

Line 78 in 204900c

Use cases include: a mobile app that has received an ID Token exchanging the ID Token with a proof of possession with a first party authorization service for an access token; an instance of a peer to peer application such as video conferencing where one instance of the application sends the ID Token with a proof of possession to a second instance to prove which user is operating the first instance.