I don't believe there is any new scope defined in this spec.

I don't think profile makes sense for a scope, as that scope is usually to go an email and name, none of which is included in our token claim. Also, would it make sense to have a scope to get the webid claim? We used to have the webid scope.

Looking at https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
It seems reasonable to have webid scope if clients expects to get webid claim in the id token. Maybe even it would make sense solid scope to get solid access token.

Mentioned in discussions on solid/authentication-panel#141 via auth panel https://hackmd.io/tI_WdIvVSd2AaMBWt0D3_Q

I would +1 solid scope rather than webid since it seems consistent with the access token's audience claim.

Note: Adding scope will require a bit of work on the client side.

I could go either way between solid and webid (with a slight preference for solid). Requiring a scope would provide a clear mechanism for clients to signal that they want a solid access token.

Overall, +1 on using a scope for this.

Can/should we transfer https://github.com/solid/authentication-panel/issues/86 & https://github.com/solid/authentication-panel/issues/146 to https://github.com/solid/solid-oidc?

I think the solid scope matched with a solid claim does make sense.

I couldn't pinpoint where the requirement is clearly expressed in the spec with a "MUST", but it seems to me that missing it is problematic.

Yes we can start transferring these issues

This was discussed during the Sept 27, 2021 meeting, and it was resolved to require the webid scope for interactions where the webid claim is provided in access/ID tokens.

A related PR is forthcoming