Coordination with IsLoggedIn

[jameshartig]

How might this proposal integrate with the IsLoggedIn proposal in the Privacy Community Group? Would this proposal actually negate the necessity for that proposal? In particular I'm having a hard time finding out what happens on reload/navigation of a page after you've logged in. Does a subsequent call to navigator.credentials.get just immediately return with the previous token or do you need to go through the whole flow again on each page? Is this something where isLoggedIn could handle the state after logging in and return the previous token?

[jameshartig]

I missed privacycg/is-logged-in#44 so I'm fine with having this closed if we think the discussion should happen in that issue instead. @johnwilander

[samuelgoto]

I'm happy to take this either way, but here is my mental model so far with regards to the relationship between isLoggedIn and WebID.

My mental model is that going through WebID should automatically imply setting setLoggedInFederated. By that I mean that whatever semantics we pick for setLoggedInFederated, they should probably be consistent with the semantics of "going through WebID".

It is still an open area of investigation, but here are some of the semantics we are exploring:

1. A website https://rp.example that successfully goes through a navigator.id.get({provider: "https://idp.example"}) is considered to be "logged in to https://rp.example with https://idp.example".
2. That unlocks, for example, https://idp.example to call navigator.id.logout(["https://rp.example"]) and have the logout endpoint of the RP be called with third party cookies (details of logout here).

Another example is:

1. A website https://rp.example that successfully goes through a navigator.id.requestAuthorization({provider: "https://idp.example", scope: "https://idp.example/calendar"}) is considered to be "logged in to https://rp.example with https://idp.example and have OAuth scopes for https://idp.example/calendar" (more details here on the authorization API).
2. That (possibly) unlocks, for example, https://rp.example to get access to refresh tokens, e.g. via embedding 3p cookied iframes of https://idp.example.

The precise semantics and "what would be allowed / permitted" as a consequence of "the browser is able to observe the sign-in event" is an active area of exploration, and one which I think we would benefit from collaborating.

That is, if setLoggedInFederated had a list of "things that would be allowed" that we could borrow that would be a useful point of coordination (and vice-versa, i.e. going through WebID should also influence the semantics of IsLoggedIn).

So, from a mental model perspective, I think "the semantics of setLoggedInFederated" is really interesting and something that we should collaborate on.

I remain skeptical that calling setLoggedInFederated directly is more useful (by that I mean, less abusable) than going through a mediated WebID flow (where the browser can explicitly capture the user's eventuality of signing-in), at least for federated identity, but you probably though about abuse more than I did, so would love to hear more from you all how you are thinking about trusting that signal without any browser UI involved.

@johnwilander @melanierichards am I making sense?

[melanierichards]

Thanks @samuelgoto, IMHO it makes sense for WebID to set this bit automatically. We'd want to look at a few things:

• How any optional parameters in SetLoggedInFederated are set/not (e.g. username), and by which party. I imagine that would be contingent upon whatever the browser is aware of in a given WebID posture. (Is this your "things that would be allowed"?)
• If for some reason the IDP would like to correct or augment a SetLoggedInFederated signal that was automatically set (or will be set) by the user agent, how would they go about doing that?
• Would IDPs like some confirmation that the bit was set on their behalf?
• Just making sure that the logged out state can also be automatically set via WebID flows.

As an FYI, this issue on the IsLoggedIn side is on the Privacy CG agenda this week; not sure if we'll get to it as there are several issues leftover from the F2F, but we may want to discuss then.

[samuelgoto]

I'm going to mark this as closed since ultimately reconciled with Login Status here:

https://github.com/fedidcg/login-status

Feel free to reopen if you feel like there is something else that needs to be acted upon.