-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarification needed on Ephemeral Identity Providers #53
Comments
I understand that by self-signed you refer to self-issued also discussed in solid/solid-oidc#91 |
I'm happy to be wrong here, but this is my understanding. If Solid is going to be a decentralized ecosystem at one end of the scale, I, a user, could spin up a pod and client application which would also be an IdP and a RS, giving me full control of my data and privacy. The other end of the scale is what we have currently, limited choice with SSO. And there is everything in between. Therefore, identity providers are ephemeral, and could be anyone - a third party service I subscribe to, my own personal IdP, or Google et al. I'm happy to change the language to make this point more clearer if others agree this is unclear, but the language may end up being a bit 'fluffy'. |
On second thought: added to the agenda to discuss at the next panel meeting - https://hackmd.io/YPvrnGl5QW6kIQ0CVtBpyQ |
To add to above, there is no technical - as opposed to social - guarantee that an identity provider will persistent for an unspecified length of time. I think that's essentially equivalent to a self-signer/issuer using an ephemeral identity provider. |
Updated the language as last discussed at the Auth Panel meeting. Latest commit on this -- 05ba10a |
@jaxoncreed does latest draft address this issue? |
This issue was resolved via 05ba10a |
In the proposed spec, it says:
The "Preexisting IdPs and vendors" use case is the one we talk about the most, but the other two are confusing and need clarification.
When "The user" is mentioned, is this the self-signed auth flow? If so, the self-signed auth flow will need to be defined in this specification as the current one isn't adequate for Solid's use case. If not, what does it mean.
I do not know a use case where a "client or application" serves as the IdP. Could that be clarified.?
The text was updated successfully, but these errors were encountered: