solid
Add Privacy Considerations for Access Token & ID Token potentially leaking data to third-parties
At present, the spec simply says what properties must be included in the Access Token and ID Token, however, it does not specify that you probably shouldn't include more information in your tokens than what is required, as that could be used as an attack vector to exfiltrate data to a malicious actor.
A lot of OAuth 2 / OpenID servers, such as Keycloak and Auth0, present Access Tokens with additional properties, such as email, first name, last name, and phone number. Given how Solid works, the access token returned from Solid OIDC could potentially be sent to a resource server that is malicious (e.g., by having a linked resource that is outside of the management of the Solid provider / intended ecosystem).
It would be very good from a security standpoint to recommend that additional properties not be added to these tokens, as they could be used to collect data without user consent. Instead, those properties should be in their public WebID Profile Document if the user wishes those properties to be public.
In OpenID Connect, there is a /userinfo endpoint, where this information could be made available, but the spec also allows this information to be in the Access Token:
- https://openid.net/specs/openid-connect-core-1_0.html#UserInfo
- https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims
I'd also suggest that we have it in security/privacy considerations, but also in the relevant sections for ID Tokens and Access Tokens have an information box “Please see the privacy considerations before adding additional properties to your ID/Access Tokens”, just to make sure implementors think twice here about potentially leaking confidential data via their tokens.
Shouldn't there be trust between Authorization Server that issues access tokens and resources server that consumes them? As I understood the Solid-OIDC, it does not bring anything new, but rather establishes the specifications used(OIDC with DPoP Access Tokens).
In #18 Authorization Server (not the OP) will be a party with pre-established trust with Resource Server. In that case, there will not be 'global' Access Tokens anymore so no issue with leaking data to third parties.
ID Token will become DPoP-bound and there we should establish some practice for security/privacy considerations of claims in ID Token. Probably we could revise existing section https://solid.github.io/solid-oidc/#privacy-token-reuse
Solid-OIDC also establishes the webid claim and corresponding webid scope. In addition, Solid-OIDC defines a mechanism for defining public client identifiers for app identification
