Currently, Solid allows a WebID to be linked to trusted identity providers through the solid:oidcIssuer predicate. While this approach resolves the validation of security tokens for an authorization server, it does not fix fundamental problems related to user experience of authentication in Solid. Additionally the tight coupling between IdP and WebID might be abused by an identity provider, such that their competitor cannot be added as a trusted oidcIssuer in the WebID Profile.
Desired solution
Ideally, we would want to define the procedure for updating a WebID to include a new solid:oidcIssuer value, if current specifications allow for this behaviour. However, given the fact that the existing WebID specification is lacking with respect to authentication, and the Solid-OIDC specification focuses on the validation of security tokens rather than related interaction patterns, this likely will not be the case.
The work of the WebID panel may be informative in how the community envisions the updating of the WebID to function within the broader ecosystem.
A solution could look like this:
Define where the specification is still lacking normative definition of the update mechanisms for the WebID.
Define the risks caused by this lack of update mechanism to the open ecosystem premise.
How does one link a new IdP to an existing WebID? The WebID specification does not provide us with any pointers. This goes in both directions, i.e. how should the IdP know that the WebID belongs to its user and how does the WebID provider know to add the IdP to the profile.
Consider the user experience of using multiple identity providers, especially if e.g. the acp:issuer attribute is used for authorizing access, how do we then know a user should log in with another IdP? If multiple IdPs are present, how should these be used in interactions with the end-user? Should we show all IdPs, and how do we prioritize them?
Acceptance criteria
A seamless integration of existing IDPs and Solid-OIDC
Pitch
Currently, Solid allows a WebID to be linked to trusted identity providers through the
solid:oidcIssuerpredicate. While this approach resolves the validation of security tokens for an authorization server, it does not fix fundamental problems related to user experience of authentication in Solid. Additionally the tight coupling between IdP and WebID might be abused by an identity provider, such that their competitor cannot be added as a trusted oidcIssuer in the WebID Profile.Desired solution
Ideally, we would want to define the procedure for updating a WebID to include a new
solid:oidcIssuervalue, if current specifications allow for this behaviour. However, given the fact that the existing WebID specification is lacking with respect to authentication, and the Solid-OIDC specification focuses on the validation of security tokens rather than related interaction patterns, this likely will not be the case.The work of the WebID panel may be informative in how the community envisions the updating of the WebID to function within the broader ecosystem.
A solution could look like this:
Acceptance criteria
Pointers
Scenarios
TBD
Notes
This challenge flows from challenge #36 and aims to make the requirements of this case more concrete.