Use Token Exchange instead

[JonasPrimbs]

I merged PR #5 and #9 and replaced the Authorization Code Grant, Refresh Token Grant, and Device Authorization Grant with a Token Exchange request.

This comes with the following advantages:

1. Simplified Specs: Instead of applying RFC6749+OIDC.Core+RFC9449 (Authorization Code Grant and Refresh Token Grant), RFC8693+draft-parecki-oauth-dpop-device-flow (Device Authorization Grant), and any other specs defining how to obtain initial authorization (CIBA?), we simply require a DPoP-bound Access Token and specify how to exchange it for a DPoP-bound ID Token. -> Solves PR Token refresh #5 and PR Device flow examples #9 with much shorter specs.
2. Future-Proof: We do not have to specify new spec extensions for authorization flows developed in the future, because they will all end up with a client obtaining a DPoP-bound Access Token.
3. Flexibility: The Token Exchange Grant specified in RFC8693 allows specifying the audience and scope of the requested token. This allows the RP to obtain an ID Token with aud = rp-frontend, and a DPoP-bound ID Token with aud = rp-backend, and request only a reduced scope for the DPoP-bound ID Token, e.g., scope = profile email for ID Token, and scope = profile for the DPoP-bound ID Token to not expose the EU's email address to third-party RPs (see the P2P video conferencing example in the introduction section). -> Solves issue Specify a dedicated DPoP-bound ID Token #7 because technically, the DPoP-bound ID Token is then a dedicated token independent from the ID Token.

[EthanHeilman]

@JonasPrimbs
Thanks for your reviews and the time you put into this PR. Using Token Exchange to request a scoped down key-bound ID Token is insightful and something I would be in favor of seeing developed further. I don't think it is a good fit for what we are trying to do with this standard.

The benefits of using Token Exchange, as I understand it, for situations in which you want to on-the-fly request an ID Token for an audience that is not the client. For instance Alice wishes to authenticate to Bob over email:

1. Her email client is the openid client, but her email client wants to present Bob an ID Token where audience is Bob.
2. Alice's email client uses Alice's access token to perform a token exchange for an ID Token specifically scoped to this authentication to Bob with only the claims that Bob needs.
3. Alice's email client sends this ID Token to Bob. Bob or whatever software Bob is using checks he is intended audience and authenticates Alice's message.

I'm working from our previous discussion and your issue here:
#7 Let me know if I misunderstood your ideas. I can see this approach being very valuable in a number of use cases not well covered by OpenID.

However the scope of what you are proposing with Token Exchange goes beyond what we are trying to do with the OpenID key-binding standard. With OpenID key-binding we are simply adding DPoP security to the traditional OpenID flows. In our standard the audience is always the client/RP. We are also attempting to stay within the existing flows and access patterns of OpenID to make this a straightforward and simple upgrade for OPs. Each of our flows involve adding a new parameter and header to existing flows. Switching to the Token exchange paradigm would require completely new request patterns. For instance there are many circumstances in which using a key-bound ID Token in a browser with non-extractable keys with greatly reduce the risk and severity of info stealers and XSS attacks. Adding this additional protection ID Tokens without requiring significant changes to OPs is a major goal of spec.

I would very supportive of this token exchange for scoped down ID Token as an extension to key binding, but I don't want to do it in this spec.

Let's know what you think.