Repository navigation
publish snapshot of pre 0.1 version (spec+primer) #250
Description
As discussed today: https://github.com/solid/specification/blob/main/meetings/2026-03-04.md#discussion-of-solid-oidc-wrt-solid26
We are talking about version before this PR, which modified both spec and the primer.
There have been a lot of other changes afterwards so I don't think we can automate much. I guess we could give a try with LLM but it would have to be heavily reviewed and we might need to have a diff to the current version for that.
@uvdsl @jeswr it would be great if someone self-assigned to it. I'm happy to provide feedback and review things, keeping in mind that I will have very limited time available before SoSy.
Another sub-issue could be reviewing test-suite linked from the spec https://solid-contrib.github.io/solid-oidc-tests/ I don't know which spec version it matches, we may also consider removing that link if we are not confident that it will match Soild 26 version.
Activity
uvdsl commentedon Apr 16, 2026
DOCUMENTATION
Found the last version with global access token:
https://github.com/solid/solid-oidc/tree/d07100df6085f5b41ebfe4b6baa0c1350be1228d
https://web.archive.org/web/20211031043811/https://solid.github.io/solid-oidc/
elf-pavlik commentedon Apr 16, 2026
It looks like there is a bit of a diff to deal with https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fweb.archive.org%2Fweb%2F20211031043811%2Fhttps%3A%2F%2Fsolid.github.io%2Fsolid-oidc%2F&doc2=https%3A%2F%2Fsolidproject.org%2FTR%2Foidc
Primer will be probably even worst, hopefully some LLMs can do a decent job on minimising those diffs.
EDIT I guess we should be looking at latest ED
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fweb.archive.org%2Fweb%2F20211031043811%2Fhttps%3A%2F%2Fsolid.github.io%2Fsolid-oidc%2F&doc2=https%3A%2F%2Fsolid.github.io%2Fsolid-oidc%2F
acoburn commentedon Apr 17, 2026
Rather trying to publish some earlier draft, would it not make more sense to modify the current editor's draft and publish a version 0.2?
I do not have a lot of context for this issue, but it seems to relate specifically to the as_uri recommendation (SHOULD), correct?
If this particular recommendation is removed from Solid-OIDC, there would be no prohibition on a resource server adding an as_uri parameter to a WWW-Authenticate challenge if it so chooses.
elf-pavlik commentedon Apr 17, 2026
Solid 26 is going to recommend version where global DPoP-bound access token is issued rather than DPoP-bound ID Token. I believe there was a
client_idclaim instead ofazpetc. @uvdsl implemented a client lib recently and should know better the diff between what is in the spec and whats implemented in CSS, NSS, PHP Solid Server etc.acoburn commentedon Apr 17, 2026
Using client_id with access tokens (rather than ID tokens) would bring Solid-OIDC more in line with https://www.rfc-editor.org/rfc/rfc9068, which would be a positive direction.
Two questions:
Solid-OIDC has historically been focused on integration with OpenID Connect, which defines ID Tokens. Is the idea to move away from that?
Secondly, if RFC 9068 is the direction you are pursuing, have you considered using the sub claim for user identity, rather than inventing the webid claim? Related to this is the question of the webid scope.
To me, the most important parts of Solid-OIDC are (1) the client identifier section and (2) the ability to constrain token use/replay (ie with DPoP)
elf-pavlik commentedon Apr 17, 2026
We mostly want to have a version which is closer to current implementations. So there will be ID Token but only for the client, even though some clients don't treat the access token as opaque and get webid from there.
Myself I wouldn't want to put too much effort on advancing Solid-OIDC and instead start adopting LWS Authn, for example as in
https://elf-pavlik.github.io/lws-auth/view/oidc/?dynamic=sequence
I guess that would be more around Soild 28. We still don't have a clear roadmap for next few years and I hope ODI, Solid CG, LWS WG and other groups will be able to start collaborating on drafting it sooner than later 🤞
uvdsl commentedon Apr 17, 2026
@acoburn, thank you for chiming in! Much appreciated!
The original idea was really just to capture what is implemented in all the maintained servers, which happens to be that the OP issues a global access token with DPoP sender constraining, with support for client identifiers, and support for RFC9207 (and other details, need to check). So I think all the parts important to you will also be part of that "back-to-the-future Solid-OIDC note".
From what I recall (it has been a while since I last looked at the tokens I got from the different servers), I believe all implementations use the
subfield with the same value as thewebidfield (if that is provided at all). To me, it makes perfect sense to usesubthat way for user identity.My memory does not serve me well on
client_idtbh, need to check that again. However I think I recall seeing some tokens whereclient_idandazphad the same value (thoughazpstems from the ID token, iirc), that is a bit fuzzy right now to me. In any case,client_idshould have been included in all the tokens I saw as otherwise client identifiers could not have been supported by the servers, I think.How the Solid Protocol will progress re authentication protocols is not too clear right now, it seems...