Skip to content
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

Closed
jaxoncreed opened this issue Jul 13, 2020 · 7 comments
Closed

Clarification needed on Ephemeral Identity Providers #53

jaxoncreed opened this issue Jul 13, 2020 · 7 comments
Labels
can-be-closed? This issue is slated to be closed Solid-OIDC Solid-OIDC Authentication Spec - Draft

Comments

@jaxoncreed
Copy link
Contributor

In the proposed spec, it says:

In a decentralized ecosystem, such as Solid, the IdP may be:

The user
Any client application, or,
Preexisting IdPs and vendors

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.?

@jaxoncreed jaxoncreed added the Solid-OIDC Solid-OIDC Authentication Spec - Draft label Jul 13, 2020
@elf-pavlik
Copy link
Member

I understand that by self-signed you refer to self-issued also discussed in solid/solid-oidc#91

@EndlessTrax
Copy link
Contributor

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'.

@EndlessTrax
Copy link
Contributor

On second thought: added to the agenda to discuss at the next panel meeting - https://hackmd.io/YPvrnGl5QW6kIQ0CVtBpyQ

@csarven
Copy link
Member

csarven commented Aug 4, 2020

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.

@EndlessTrax
Copy link
Contributor

Updated the language as last discussed at the Auth Panel meeting. Latest commit on this -- 05ba10a

@elf-pavlik
Copy link
Member

@acoburn acoburn added the can-be-closed? This issue is slated to be closed label Jan 15, 2021
@acoburn
Copy link
Member

acoburn commented Jan 25, 2021

This issue was resolved via 05ba10a
Feel free to re-open if further clarification is needed.

@acoburn acoburn closed this as completed Jan 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
can-be-closed? This issue is slated to be closed Solid-OIDC Solid-OIDC Authentication Spec - Draft
Projects
None yet
Development

No branches or pull requests

5 participants