inrupt
Support for Solid-OIDC v0.1.0 (with UMA AS)
Search terms you've used
UMA, as_uri, claim_token
Impacted environment
In which environment would the proposed feature apply ?
- [x] The browser
- [x] Node.js
- [x] Other (please specify): ...
Any environment which the library wants to support: Dyno, Bun etc.
Feature suggestion
Support for https://solidproject.org/TR/oidc (published on 2022-03-28)
Expected functionality/enhancement
Client should use DPoP bound ID token and push it as a claim to UMA AS.
Access tokens shouldn't cross security domains and only be used with RS which advertised the AS with as_uri
Actual functionality/enhancement
Use Cases
There is an open source Keycloack extension coming which conforms to the published Solid-OIDC draft https://github.com/CarrettiPro/keycloak-solid
Preferably this client should be able to work with it.
Hi @elf-pavlik, thanks for reaching out. This is indeed a planned improvement of this library, for which the timing still hasn't been determined.
Hi @NSeydoux. I'm hoping to bring up the broader issue of implementations for Solid-OIDC v0.1.0 during next week's Solid CG meetings. If someone will step up to contribute this update and/or secure funding for that work. Should they know about any prior design work or just assume that they will need to PR it starting from the main branch? I believe this issue could be used to have initial discussion about planned design.
Also please note that, clients currently doesn't send dpop bound ath claim in dpop proof. Current dpop protocol requires it.
See the issue https://github.com/manomayam/manas/issues/27 for other client side idiosynchronies.
There has been some prior work indeed: the intent is for this library to implement a so-called Reactive Authentication pattern, an instance of which is already implemented in https://github.com/inrupt/solid-client-java. At a high level, this means instead of preemptively sending the global access token, an authenticated session would hold on to credentials (including but not limited to the ID Token), and go through the UMA flow to dynamically negotiate with the Authorization Server which credentials should be used as claim tokens to get access to the target Resource.
I am happy to get into more details if someone is interested to contribute, but I have to say, I anticipate this to be a significant undertaking that involves a lot of internal refactoring of the library.
Any news on this?
It would be great that this library supports Solid-OIDC v0.1.0!
So we could build apps that follow the current spec :)
