Capture Solid-OIDC with Global Access Token

[uvdsl]

Addresses #250 and captures the authentication flow that all current server and client implementations support (as of 2026-04-21).

This specification version is a snapshot of Solid-OIDC, where a Client uses a global DPOP-bound access token issued by an OpenID Provider to authenticate at an Resource Server.

[elf-pavlik]

Since we don't have simple setup to preview it i improvised one here: https://elf-pavlik.github.io/solid-oidc/

Here's the diff: https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fsolid.github.io%2Fsolid-oidc%2F&doc2=https%3A%2F%2Felf-pavlik.github.io%2Fsolid-oidc%2F

[uvdsl]

That does look a bit weird at times :) I'd recommend checking this branch out and building locally and simply compare manually. The Diff is surprisingly small.

[elf-pavlik]

As I understand the main snapshot will go to https://github.com/solid/specification/
Maybe instead of having snapshot-gat directory we just keep the branch that modifies index.bs and sequence.mmd directly. Possibly also the primer at some point, we could add protection to that pranch as well and keep it in the repo after publication.

[uvdsl]

I thought that this repo would be the best place, given that the issue was logged here and the trace of origin of this snapshot is here. 🤷 I just want this to be done, so I can go back to drafting the other documents I need to work on.

[elf-pavlik]

Please just go ahead and do it the way you find the most convenient!

[elf-pavlik]

@uvdsl this version is missing Client Credentials section, is it intentional or something still on TODO?

• feat: add client credentials as a MUST #245

[uvdsl]

That was indeed intentional, afaik, not all current implementations support that flow. I only know of CSS and ESS. Not sure about all the others...?

[acoburn]

I was under the impression that the Client Credential section was added specifically for Solid26.

[elf-pavlik]

We will attempt to clarify it tomorrow during CG meeting @jeswr @langsamu

[uvdsl]

I am fine to include it if there is at least a call to implementers. 🙂 I just wasn't sure if that was what was intended by all.

EDIT: I think it depends on what that snapshot should try to do... reflect what ALL the servers DO support or reflect what ALL the servers SHOULD support...

[acoburn]

There are two conflicting stated purposes in this change.

First, this change claims to roll back to a point before the 0.1 release and second, that it reflects all current implementations.

Regarding the first point, there was never a time that this specification described the use of access tokens. It has always defined requirements on the structure and use of ID tokens. I am not opposed to that change per se, but it is not a rolling back to an earlier state.

Secondly, this change introduces an new requirement that has never previously existed: that the access token be a JWT. Aside from conflicting with the first stated purposes, this significantly changes how clients process responses from an OP's token endpoint.

From the perspective of OpenID Connect, an access token is scoped to the OP itself, particularly the user_info endpoint. There is also no requirement (per OIDC) that an access token be a JWT. The change here adds a new requirement on servers and a new behavior for clients.

I am not necessarily opposed to these changes as part of a future version (e.g., 0.2) of this specification, but I do object to the claim that this reflects an earlier version of this spec and also reflects what everyone already supports.

[elf-pavlik]

@acoburn have you looked at the version mentioned in

• publish snapshot of pre 0.1 version (spec+primer) #250 (comment)

https://web.archive.org/web/20211031043811/https://solid.github.io/solid-oidc/#tokens-access

This was pretty close to what was drafted by Adam and Ricky contracted by Inrupt

[elf-pavlik]

As I mentioned this PR will be discussed today during the CG call https://www.w3.org/events/meetings/9d3965a2-f4a0-4346-8ca6-8eadee10051c/20260422T140000/

This is the last CG call before the SoSy, next week is canceled due to the Solid Week.

[uvdsl]

@acoburn, I pulled the contents directly from the linked commits, compared using gitlense, and merged the two - rolling back the token section while keeping the newer sections on client id, issuer validation, security and privacy considerations. I did not invent new content here, please check the commit history and the web archive to refresh your memory.

I did add clarifications on token validation, as this is critical to security. Maybe you stumbled over those?

Again, this is meant to reflect a snapshot of something past. Not the next iteration for Solid-OIDC.
Please note that this PR is not merging into the ED but creating a separate document.

[uvdsl]

@acoburn:

I do object to the claim that this reflects an earlier version of this spec and also reflects what everyone already supports. [Source]

The claim is based on my implementation experience from https://github.com/uvdsl/solid-oidc-client-browser, from checking on the server implementations (CSS, NSS, ESS, ...) for reference, confirming my understanding of the behavior of @inrupt/solid-client-authn-browser, and from discussion with the community.

@acoburn, could you please detail the grounds for your objection?

@jeswr, could you clarify the intent behind publishing this snapshot for Solid26?

[acoburn]

@uvdsl my point is that the published version 0.1 represents the authentication panel consensus at the time of publication (Mar 2022), and that version specifies the use of an ID Token. Please also note that Solid-OIDC is based on the prior work of WebID-OIDC, which also used ID tokens.

There are two ways specifications are generally adapted -- a new version is published (one which represents that consensus of the authors/editors/community) or a fork is created and published as a different document. I would support either of those approaches.

Had the version you reference here been published by the authentication panel (e.g., as a 0.03 version), there would be no discussion here, and Solid26 could just reference that, but there is no version 0.03. My concern is that, by cherry-picking commits from the Solid-OIDC repository and changing the requirements, this only adds confusion to what is a fundamental part of the security of Solid.

My strong preference would be to make these changes as a PR on main and, once merged, publish a 0.2 version of this specification.

[uvdsl]

@acoburn thank you for elaborating your main concern is about the consensus aspect rather than reflecting implementation reality. I absolutely share your concerns on confusing the target audience.

This work was requested by ODI (via @jeswr) for Solid26 specifically. I am happy to immediately close this PR and drop any effort on this if this work is not desired anymore. 🤷

[acoburn]

As discussed in the Solid CG meeting on 2026-04-22, we agreed on three changes, all of which will target the main branch and help lead us to a 0.2 publication (timeline of that publication TBD, but hopefully soon)

• A PR that removes the UMA references and as_uri property from WWW-Authenticate response headers - this reflects the observation that there exist very few server implementations that support UMA and possibly no open source implementations.
• A PR that changes the requirements from using an ID token as an authentication credential to using the DPoP bound access token from the OpenID Connect provider - this reflects the observation that most (or all) client and server implementations already support this. This is a conceptually significant change -- though one that likely will not be controversial -- so having visibility of the change in a single PR would be beneficial
• A PR that changes the MUST requirement for the client_credentials flow to a SHOULD - this reflects that fact that some server implementations already support client credentials but not all do so.