What do you think to use IRI of the spec as scope, as in https://solid.github.io/authentication-panel/solid-oidc/#discovery

This way the spec would specify conformance criteria #20 for each role in the ecosystem.

With this approach we could extend / amend it in the future by publishing updated spec with new IRI.

Using IRI for claim also seems to be in line with JWT spec

RFC 7519 - JSON Web Token (JWT)

4.2. Public Claim Names

Claim Names can be defined at will by those using JWTs. However, in
order to prevent collisions, any new Claim Name should either be
registered in the IANA "JSON Web Token Claims" registry established
by Section 10.1 or be a Public Name: a value that contains a
Collision-Resistant Name. In each case, the definer of the name or
value needs to take reasonable precautions to make sure they are in
control of the part of the namespace they use to define the Claim
Name.

Just to follow-up with the discussion I kind of like the idea of keeping consistency by moving from webid to solid there, if specifying the IRI is just passing a static string to the area of the specification why not.

I have no strong opinion about the possible length of the associated IRI and the possible overhead of the request size but the scenario deserves some attention I think.

I like the idea of having a future-proof claim in Solid OIDC Access & ID Tokens.

Alternatively to changing the webid claim to solid, the possibility of adding other schemes to the WebID specification, which is currently a draft was raised. Extending WebIDs to other schemes seems regardless of the resolution of this issue like a good idea. @bblfish do you have an idea of where to best raise this?

I am a bit unclear on whether we should generalise the webid claim to solid in the perspective of using it for things such as verifiable credentials since a WebID and a Verifiable Credential seem to be different enough to potentially warrant a specific processing by authentication and authorization engines.

I would be very much in favor of requiring a solid scope for OIDC client registration as per https://github.com/solid/authentication-panel/issues/86.

On the IRI vs IANA registered claim name, I would lean towards IANA registration. The overhead of IRI size is one concern, consistency with other claim names is another as well as the fact that leaking RDF/linked data style identifiers into JSON will probably just cause confusion rather than positively spike curiosity.

See also: https://hackmd.io/VZ2T6RgFQQqFjobDXJ0BsA

Maybe we could define the claim as:

The "solid" claim is an IRI that identifies the agent that the JWT is intended for. Each Solid Resource Server intending to process the JWT MUST verify the identify of agents via the solid claim.

Picking up this thread with regards to the linked issues.

Would there be advantages to having only a single claim that has to incorporate all possible ways of identifying in the Solid ecosystem? I.m.o. a single scope (e.g. solid) that per specification includes a number of different claims (e.g. webid, did, vc) seems to take the sweet spot of clarity and useability.