@RubenVerborgh wrote:
Edge case indeed, but it has major architectural consequences. All current Solid client s> ftware assumes that the user is logged in with one WebID.
What does current mean in this context?
I personally do not know any Solid software that assumes a user can be logged in to different pods with different WebIDs. Or said differently: all Solid software assumes that the user is logged in with the same WebID to all hosts.
For example, you can ask rdflib.js about the WebID of the current user, but this is one string, whereas reality is different for WebID-TLS.
Would you know any of our software that does think about this?
Can you log in as different WebIDs from different origin?
With WebID-TLS as supported by current browsers, any combination of “request origin + destination origin” can have a different WebID associated with it.
For example, the user could use Web app A to access hosts B and C while using different WebIDs on B and C. The app A could detect this, but cannot change this.
In WebID-OIDC, the client can (and the current client does) ensure one WebID for access to B and C.
In different windows (im thinking incognito windows that dont require a restart)?
No, the WebID with WebID-TLS is determined by “request origin + destination origin”, window is not a factor.
Let’s nail down what’s being said here. Something like “solid auth client assumes a single WebID for a given origin, in a given browser session” – something like this.
All Solid software apps and libraries that I know about, assume that the user is identified by one single WebID.
This assumption is correct for WebID-OIDC, but not for WebID-TLS.
In WebID-TLS in browsers, there is no concept of “the user is logged in as X”. There is only a concept of “for requests from origin A to server B, the user uses identity X” for different combinations of A and B.
WebID-OIDC was proposed to run alongside WebID-TLS, not to replace it. So there’s going to be push back if that is changed.
I understand the pushback, but the proposal was not grounded in reality. It is not possible to run them alongside (from JavaScript client applications) as it was proposed. We need a higher level of abstraction to consider WebID-TLS alongside WebID-OIDC in a consistent way. The old assumptions were incorrect, as issues such as #138 (comment) have revealed.
There has been some discussion on Clarify authentication possibilities and limitations for WebID-TLS and WebID-OIDC · Issue #152 · solid/solid · GitHub with @melvincarvalho and would like to invite more here.