Re: Authentication draft: difference between dpop-bound access token and oidc id token

Good question!
Isn't the id token used by the client to create the Authorization header?

I created a github issue pointing to this ML thread, here:
https://github.com/solid/authentication-panel/issues/78

Cheers,
Michiel.

On Tue, Oct 6, 2020 at 11:47 AM divoplade <d@divoplade.fr> wrote:

> Dear authentication panel,
>
> I am working on implementing the draft at
>
> https://github.com/solid/authentication-panel/blob/master/oidc-authentication.md
> (for the GNU Guile software ecosystem).
>
> In the DPoP draft, two objects are mentioned:
> 1. The DPoP proof, containing fields such as htu and htm, signed by an
> ad-hoc key present in the JWT header ;
> 2. The access token, signed by the identity provider, containing
> traditional oidc token fields such as sub, iss, aud, and most
> importantly the cnf field to confirm the ad-hoc key used in the proof.
>
> The authentication panel draft mentions two objects that are returned
> by the identity provider to the client:
> a. The access token, which is the same as the DPoP bound access token
> (see 2.);
> b. An OIDC ID token, which looks suspiciously similar but does not use
> the jkt header and has a different aud clause.
>
> Both a. and b. are signed by the identity provider.
>
> Is b. maintained here for backwards compatibility? The only difference
> I see is the meaning of the audience (aud) clause. If so, why ignore it
> in the following section, Resource Access?
>
> If I understand correctly, the Resource Access section should read in
> its introduction that the Resource server receives a dpop-bound access
> token + a dpop proof, OR an OIDC ID token, and give an example of dpop
> proof so that it is clear to the reader that the specification uses
> three different types of JWTs: DPoP-bound access token, non-DPoP OIDC
> token, and DPoP proof.
>
> If I did not understand some important thing, please let me know.
>
> Best regards,
>
> divoplade
>
>
>
>

Received on Tuesday, 6 October 2020 10:03:03 UTC