Device flow examples

[EthanHeilman]

Main change

• Adds device flow sections and examples

Minor changes

• Adds auth code example
• Fixes broken references to RFC8628

The code for generating the DPoP blobs examples can be found in this commit https://github.com/EthanHeilman/oidc-jwk-go/commit/2a78004016b4844a1047689b2a5e9a3b23d0dfa4

[dickhardt]

lgtm

[JonasPrimbs]

According to Section 3.1 of RFC 8628, I recommend the following changes:

1. Query parameters should be body parameters
2. The path should be /device_authorization to be consistent with the example from Section 3.1 of RFC 8628
3. In Section 3.1 of draft-parecki-oauth-dpop-device-flow-00, instead of providing the JKT, the DPoP header is used instead. It might be worth a discussion on which one is better.

[EthanHeilman]

Addressed 1 and 2.

All the flows in OAuth DPoP flow in RFC 9449 use JKT, I don't understand the justification for why that draft deviates from this. Since no public key has been established, is it just using the full DPoP to communicate the public key it wishes to use? I am curious now, maybe I am missing something important.

@aaronpk Do you know why a full DPOP was used here rather than the JKT?

[JonasPrimbs]

300000 (~83 hours) seems very long; I would prefer using 1800 (30 minutes) as in Section 3.2 of RFC8628 because values from examples often turn into the default values of future implementations.

[EthanHeilman]

Addressed, changed to 1800

[JonasPrimbs]

I commented all suggested changes inline, mainly formatting and consistency issues to comply with other RFCs.
I also compared the Device Authorization Flow with the expired draft of Aaron and Brian. The main difference seems to be in the Device Authorization Request (providing just the dpop-jkt vs. sending a DPoP Header with the request).

With the perspective, that the DPoP-bound ID Token might not be the last DPoP-bound token ever needed in OAuth or OpenID Connect, it would be nice not having to specify the token request and token refresh over and over again. Maybe the better way would be sourcing out the DPoP-bound token request mechanisms to other specs (RFC 9449 for authorization code, draft-parecki-oauth-dpop-device-flow for the device flow, future grant type specs should include the DPoP way) and using a token exchange (RFC 8693) with or without DPoP to obtain other tokens (such as the DPoP-bound ID Token).

I will try to find some time proposing the corresponding changes for this draft next week as a pull request. I guess it would be much cleaner just describing a DPoP-bound token exchange instead of describing the authorization code flow, device authorization flow and refresh token flow.

[EthanHeilman]

@JonasPrimbs Addressed review comments, look it over and let me know if you are good with this PR

In terms of #12, I responded on that issue. Token exchange for single purpose ID Tokens is a great idea but out of scope for the goals of key binding. Worth creating as a separate standard.

[JonasPrimbs]

Looks good, I think the PR is ready to merge.