- From: Michiel de Jong <michiel@unhosted.org>
- Date: Tue, 6 Oct 2020 12:02:38 +0200
- To: divoplade <d@divoplade.fr>
- Cc: public-solid <public-solid@w3.org>
- Message-ID: <CA+aD3u25kQpLUNPbuY6vLqocux2wrc+2d7fSKD8T-7ig9y+zdA@mail.gmail.com>
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