- From: divoplade <d@divoplade.fr>
- Date: Tue, 06 Oct 2020 08:25:45 +0200
- To: public-solid@w3.org
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 09:46:10 UTC