Proposal: change webid claim to solid

[acoburn]

This is a proposal to change the webid claim to solid in access tokens and ID tokens.

The background for this is severalfold:

1. The current webid claim is very WebID specific, and WebIDs are (according to the draft WebID specification) limited to HTTPS URLs. If other types of identifiers are to be supported (e.g. DIDs, VCs), placing those in the webid claim is questionable. A solid claim would therefore be more flexible and, arguably, forward looking.
2. The names used by Solid-OIDC have generally been moving toward "Solid" and away from "WebID". The specification name is Solid-OIDC (it was formerly WebID-OIDC). The audience claim for access tokens uses a value of solid to indicate that the token should be used with the Solid ecosystem.
3. WebIDs will continue to be supported with a solid claim and will likely continue to be the main identifier format for agents in the near term
4. There is a discussion to use a scope value with Solid-OIDC, and there is an indication that this scope could be solid. If the name of that scope is, in fact, solid, then using a solid claim in the resulting tokens would make for a simple, consistent naming structure.

If the name of this claim is changed to solid, we should constrain the value(s) to be IRIs.

This change would place no new requirements on Solid components to support DIDs, but it does make support of DIDs more possible for the future.

This change would require adjustments on client apps (RP), Pod servers (RS) and identity providers (OP).

[elf-pavlik]

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 solid/solid-oidc#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.

[elf-pavlik]

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.

[balessan]

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.

[matthieubosquet]

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

[matthieubosquet]

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.

[woutermont]

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.