Define Behaviour for Multiple OpenId issuers for a WebID

[jaxoncreed]

As a reference to this issue: https://github.com/solid/node-solid-server/issues/1266

Currently, the Solid spec does not explicitly define behaviour for a user who's WebID lists multiple OpenID issuers. The normative spec should indicate that when dereferencing a WebID's issuers a server must not reject a token if any of the issuers match the issuer in the token.

[elf-pavlik]

If we go with requiring User's IdP to also act as User associated Authorization Server it may mean that in practice User would need to choose one. Otherwise Which AS would stay responsible for managing user authorizations for which client?

[TallTed]

@elf-pavlik

in practice User would need to choose one

for each interaction.

What happens if you set up an account based on an ID from IdP A, which lists IdP A+B+C, using IdP B as initial AS, and then IdP goes down, temporarily or permanently? Should you be unable to get authorization based on authentication with IdP A or C?

[jaxoncreed]

What happens if you set up an account based on an ID from IdP A... and then IdP goes down, temporarily or permanently

The user's ID is not on the IDP, the webID would be something completely separate, so if the WebID goes down, then that's a whole different problem. But in short, no, if your WebID goes down you should not be able to get authorization based on any IDP.

[elf-pavlik]

for each interaction.

I think if someone would use multiple Authorization Server, that User most likely will pick one AS for any given Client (app). I guess app doing discovery before asking User for authorization it could ask which AS that User wants to use with that app.

The user's ID is not on the IDP

Yes, we don't make any assumption about where User publishes one's WebID Profile.

[RubenVerborgh]

Side-notes that:

• oidcIssuer is probably not the correct name (more something like "trusted identity provider")
• the fact that the value of oidcIssuer is plaintext, might not be desired; this could invite people to DDOS attacks on a private IDP etc. Instead, we might want some cryptographic value here, such that the IDP can prove it can act on my behalf.

[elf-pavlik]

the fact that the value of 'oidcIssuer' is plaintext, might not be desired

I think one should be able to enter one's own WebID in the app and let it discover all the rest. Also one could do DDOS attack directly on WebID, especially that many deployments may choose to run storage server and identity provider together.

[RubenVerborgh]

I think one should be able to enter one's own WebID in the app and let it discover all the rest.

There are use cases for both; some might want to enter their IDP, some their WebID.

For usability arguments (which are important), neither is probably optimal. Browser autocompletion seems like a good direction.

[dmitrizagidulin]

@RubenVerborgh

oidcIssuer is probably not the correct name (more something like "trusted identity provider")

Hmm, I'm not sure. That triple is specifically for OIDC provider semantics. (Maybe we can have rdfs or owl subclass or whatever, so that one can infer that it's a subset of "trusted identity provider"?)

the fact that the value of oidcIssuer is plaintext, might not be desired; this could invite people to DDOS attacks on a private IDP etc. Instead, we might want some cryptographic value here, such that the IDP can prove it can act on my behalf.

Oooooh interesting! That's a really great question.

(I've opened an issue about this on the DID Spec repo, since it might be of interest to the DID community as well.)

[elf-pavlik]

I think wording based around "Statement matching triple ?sub <http://www.w3.org/ns/solid/terms#oidcIssuer> ?iss covers issued by any of user designated issuers. For DDOS we may need to create separate issue.

[acoburn]

I think wording based around "Statement matching triple ?sub http://www.w3.org/ns/solid/terms#oidcIssuer ?iss covers issued by any of user designated issuers.

As stated above, this current Solid-OIDC specification draft answers this question: https://solid.github.io/authentication-panel/solid-oidc/#resource-access-validation