so if i understand you correct, that it is:
curl --location --request POST 'https://solidcommunity.net/authorize' \
--header 'Content-Type: application/json' \
--data-raw '{
"response_type":"code",
"client_id":"2ee6e1aebef0f7491462242faa45fd0b",
"scope":"openid",
"redirect_uri":"https://app.example/oidc_callback"
}
'
with this request here, i get the login HTML site. That is maybe correct, but i don't want to run in the browser ;-(
Proposing agenda item for the next meeting (today): https://github.com/WICG/WebID/issues/41#issuecomment-716446481 (see rest of the repo for details on WICG's WebID re authentication space). There is a TPAC breakout session on WICG/WebID: https://www.w3.org/2020/10/TPAC/breakout-schedule.html#webid .
As said, we (Solid CG) should identify areas where they may be synergy with the WICG looking into "WebID".
I tweaked the GitHub actions as part of the pull request.
The name collision is significant but a temporary issue if addressed soon. This is where communities acting in good faith goes a long way.
A much bigger and a long-term issue is communities addressing similar problems/needs re Web identifiers (and linked identities) and authentication - at least the rough bits right now if we compare their notes with ours. Soon enough it will affect authorization, payments...
This is all part of a broad and complicated discussion involving different communities with their preferred stuff. And, it is in the camp of age old issues eg. identity in the browser, formats, .. through OWP.
I suggest that we identify areas where synergy may - should! - be possible. Components/mechanisms that UAs can handle natively or provide good support would be preferable than using/injecting separate libraries/systems. (Related obvious example: it doesn't take much to know that browsers natively handling RDF parsing/serializing would make things heck of a lot simpler/better for developers and end-users than...)
Perhaps we need an issue on this in solid/specification or solid/authentication-panel ... but first I suggest that we review their WIP, come up with the overlap/delta.. and discuss with WICG. Relatively simple: Could/Will they use RWW/Solid's WebID? Same same but different? (Their examples seems to be using domains or emails, and seems to have room for DIDs... so WebID can also be part of the picture) Complex: authentication.. what does that entail for the Solid ecosystem? Obviously we don't want to be in a situation where browsers natively do something similar to what Solid proposes. If sufficiently compatible, it'll be easy to transition I presume, but my concern is that we should not end up in that situation, if we take the right steps, now.
i get the userinfo_endpoint: https://solidcommunity.net/userinfo
But if i call the https://solidcommunity.net/userinfo i get an time out.
Any Idea ?
It's also worth mentioning that while traditional OpenID Connect use cases are concerned with retrieving user-related claims from UserInfo endpoints, most WebID based systems replace the UserInfo mechanism with the contents of WebID Profile documents.
https://github.com/naturzukunft/keycloak-springsecurity5-sample
thanks !