privacycg / is-logged-in Goto Github PK

View Code? Open in Web Editor NEW

91.0 91.0 10.0 56 KB

The IsLoggedIn API

Makefile 100.00%

is-logged-in's People

Contributors

Stargazers

Watchers

Forkers

taiareerob melanierichards silentimp apogee1776 samuelgoto

is-logged-in's Issues

Integration with FedCM (formerly WebID)

Federated logins, i.e. login on a relying website from OrganizationA through an Identity Provider (IDP) from OrganizationB, have been discussed for IsLoggedIn all along. See for instance issue 35 and issue 30.

WebID could potentially be integrated with IsLoggedIn by becoming a standardized "mediated login" which makes it easy for the browser to reason about the user's login state and provide a nice path for both the identity provider and the relying website to set IsLoggedIn.

We should work with the WebID team to see if such an integration makes sense.

Use the term bucket for storage

Storage folks are talking about expiring buckets of storage, a bit of storage inside an origin. We should possibly reason about buckets and the expiry of them rather than cookies and IndexedDB.

Safari implementation of setLoggedIn API

Hi.
I was trying to experiment with setLoggedIn API in Safari, where it present under a flag.
It appears that isLoggedin always resolved with true and navigator.setLoggedIn or navigator.setLoggedOut are resolved with undefined without any visible influence on navigator.isLoggedIn results;
Result is the same over https and http.
Same result if I am getting password/username with navigator.credentials.get.
Maybe you could help me to understand what I am doing wrong?

https://gist.github.com/SilentImp/7555e60daa4b13d830259a8622c8ecf5 — gist with code.

code:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>isLoggedIn API</title>
</head>
<body>
  <header>
    <button id="signin" type="button">Sign-in</button>
    <button id="signout" type="button">Sign-out</button>
  </header>

  <main>
    User is <output id="output"></output>
  </main>

  <script>
    (async () => {
      if (!navigator.isLoggedIn) return;
      
      const signIn = document.getElementById('signin');
      const signOut = document.getElementById('signout');
      const output = document.getElementById('output');

      const checkIsLoggedIn = async () => {
        const isLoggedIn = await navigator.isLoggedIn(); // It looks like always resolved with `true`.
        console.log('isLoggedIn: ', isLoggedIn);
        output.innerText = isLoggedIn ? 'authenticated' : 'anonimus';
      }

      signIn.addEventListener('click', async (event) => {
        try {
          console.log(navigator.setLoggedIn);
          const response1 = await navigator.setLoggedIn({
            username: "silentimp",
            credentialTokenType: "legacyAuthCookie"
          });  // resolved with `undefined`.
          console.log(response1);
          const response2 = await navigator.setLoggedIn("silentimp", "legacyAuthCookie"); // resolved with `undefined`.
          console.log(response2);
          checkIsLoggedIn();
        } catch (error) {
          console.log(error);
        }
      });

      signOut.addEventListener('click', async (event) => {
        const response = await navigator.setLoggedOut("silentimp");  // resolved with `undefined`.
        console.log(response);
        checkIsLoggedIn();
      });

      checkIsLoggedIn();

    })();
  </script>
</body>
</html>

Would it be possible to have it isomorphic?

Hi.
This API could be even more useful, if it would be possible to use it on backend too.
Maybe with polyfill and cookies, or something?

Can we cater for link-based logins, e.g. tap link in email => logged in

Both account recovery flows and so called password-less logins may use links with authentication tokens in them. A tap or click logs the user in as long as the token is valid. Could we formalize such links and usage of them to the point where it could be reliably detected as a login flow?

Should we standardize how we expect browsers to use this signal?

Our discussion on the teleconference today makes me wonder whether we should try to standardize the isLoggedIn "signal" independent of how browsers plan to use the signal. The questions from Ben show that there are a lot of different ways we could imagine using the signal, and I don't think we're aligned.

A couple of the possible applications we discussed today:

Long-term access to client-side storage (in the first-party context)
Access to certain powerful browser APIs

FWIW I also brought this question up on a previous call and John shared that he'd like to keep the API small in scope.

3p access to isLoggedIn

Continuation of privacycg/storage-access#8 (comment) and I think this is slightly different than #13.

One problem brought up in the Storage Access proposal is that third-parties don't know when the user is logged in and when it is appropriate to prompt for storage access on click. An example was a video player that doesn't want to show you ads if you're paying but doesn't want to ask for storage access on every "play" action. Additionally, it can be a better user experience to show some logged in state in the iframe instead of needing to always gate/hide content behind a button especially across page navigations.

The problem that Chrome brought up is that the logged in identity can be a huge fingerprinting signal. Since you can only get 1-bit of information from navigator.isLoggedIn() I'm not sure how much that helps fingerprinting but if username or other data is eventually exposed via the API, those can be disallowed in a 3p context. Alternatively, the isLoggedIn state could be partitioned based on the top-level origin. This would solve the problem above where you're logged into a widget but then navigate to a new page or refresh and you're now shown the logged out status again. When the iframe is granted storage access it could check that the user is, in fact, logged in (based on cookies or something else) and update the isLoggedIn state, which would then persist for this partition.

Mediated vs Unmediated Logins

"Managed logins" is useful way of expressing that the browser was involved in the user just logging in.

Likewise, "Unmanaged logins" can codify all the cases where the browser is not involved and just get the signal from the website that the user is logged in.

We propose this spec uses the terms managed and unmanaged logins for this purpose.

Consider IsLoggedIn as requirement for document.requestStorageAccess()

The Storage Access API and its document.requestStorageAccess() is intended for authenticated embeds. We should consider a requirement to have IsLoggedIn be set to be able to be granted storage access as a third-party.

Supporting display name and avoiding misuse of them

Porting to this repo; @johnwilander wrote:

We've discussed display name as a version of the username suitable for user interfaces. This would allow the browser to show an account name that the user might be more familiar with. The user might have the formal username liza_johnson887 but the desired display name Lizza JSON. Can we support that in a safe way?

We have to make sure it cannot be misused to fake trusted browser signals. Imagine display names such as "Secure," "Private," "Logged Out," or "Anonymous," and the browser showing them in various contexts. Add localization to that and you have a real challenge. Add multi script such as Latin+Cyrillic and I'm remembering the struggle to defend URLs as a trust signal.

Describe the structure of `optionalParams`

This issue was ported from WebKit/explainers#40.

Many methods in the spec take an optionalParams argument but nothing documents what is allowed in there.

Prevent 1p websites from fingerprinting IsLoggedIn state in 3p iframes

This issue was ported from WebKit/explainers#43

(Cross-post of privacycg/storage-access#8 (comment) — if that's not ok, let me know)

I think IsLoggedIn is a good idea overall, but one very minor concern I have is that it's a little easier to use it in a way that could be abused, than it is to use it in a defensive way.

Specifically, it's easy to write the 3P iframe script to check if isLoggedIn() and communicate it to the 1P without anyone validating that this 1P is someone the 3P wants to communicate with. And if a lot of sites have 3P iframe scripts lacking validation, they could be collected into a fingerprint. This validation is potentially something that the 3P iframe script has to go out of its way to do, which is bad because ideally, the path of least resistance ought to also be the most likely secure one.

It could turn out that this isn't an issue in practice—maybe 3P iframe scripts will usually require an API token from the 1P; or maybe 3P iframe scripts usually won't communicate logged-in status to the 1P in the first place, they just show or don't show a Log In button, and the only indication of whether login was one-click or required a popup is the delay from mouseenter over the iframe to successful login being reported to the 1P (which, due to user interaction requirement, couldn't be realistically collected into a fingerprint).

I don't have any particularly clever ideas for how to address my concern. The obvious idea that occurs to me is to add a required argument to navigator.setLoggedIn(), domains, which would be a space-delimited list of domains, or '*dangerous-allow-any*'. Empty string '' or undefined would be an error. Documentation would advise that if you use '*dangerous-allow-any*', you need to do your own validation of the 1P like checking an API token or ensuring that information from navigator.isLoggedIn() doesn't leak out of the iframe, lest you be unwittingly roped into a tracker's fingerprint (you could even threaten to add such unsafe 3P iframe scripts to a browser block list, to include an element of self-interest).

(I initially thought of just '*' to allow any domain, but I think having the word dangerous in the keyword is important because it's likely to be used in tutorials for expediency, and while '*' can be glossed over, '*dangerous-allow-any*' will demand explanation.)

If there are better ideas, I'd love to hear them?

File issues for each item in the Feedback Received section of the explainer

There are a number of open IsLoggedIn issues in the WebKit/explainers repo. Please triage them and port them over here.

Replaced by FedCM login-status API?

Is https://github.com/fedidcg/login-status replacing this proposal?

Support for logins to sites requiring 2FA login

This issuer relates to #9 but given the amount of discussions on the original Rememberme function its probably better to log this as a separate request/requirement to consider.

The original post from @melanierichards on #9 referred to the bank website login usecase. Banks don’t typically allow a user to remain logged in across sessions. They need to protect their users, while still aiming to make the login process easier.
The industry best-practice for a high-security login situations is two-factor authentication (2FA). Choose 2 factors from:

Something you know (e.g. password/PIN)
Something you have/possession (e.g. SMS OTP, Trusted Mobile App, Hardware device)
Something you are (e.g. face or fingerprint biometrics).

Supplying all of these at a login or step-up can be painful. WebAuthn will start to improve this, but there are still a number of cases where this is not supported, or where a device pin/biometric is not appropriate (e.g. multiple people in a family has their fingerprints setup on the device).

The possession factor is a key element. In fact, many banking apps start off by asking you to ‘Register’ the app before you can login. They use full 2FA based on existing authentication elements, and then mark the app identity as a trusted device for this user. For future logins, only a password or PIN is asked, with the app being considered as the possession factor from thereon forwards.

Could we not enable a similar capability for browsers. Basically a user will still perform 2FA (e.g. some form of OTP or Out of Band push to their Banking App). After that is completed however, we could allow a customer to trust/Register a browser for this domain. To some extent this is already done today via Cookies or IndexedDB. Today however, these may be cleared if user does not regularly return to the site. And that then results in legitimate implementations having to fall back to device fingerprinting, which is of course not ideal.

The goal is to allow a better user experience on these trusted browsers, by allowing users to consent to it. If they don't want it, they can still login with a more explicit 2FA authentication every time. I think it relates to 'ExpectsPersistentState' that @ajknox mentioned or perhaps even 'RememberDevice' mentioned by @johnwilander.

What if we created an explicit call to allow the browser to get user consent (e.g. setTrustedBrowser)? The browser would then ask the user if they would like to trust/register this browser. It could include a default duration that could be selected. E.g. "Trust this browser for 3 months to improve your bank.com logins". With this consent the browser could then get a clear signal that bank.com’s Cookies and IndexedDB storage should be maintained for the approved duration. After this duration expires, the user could also be prompted to renew (“You previously indicated that you want to trust bank.com for logins. Would you like to renew that for another 3 months?”).

This mechanism would really help current sites that are using cookies or information for legitimate reasons to help create a better user experience for end-user.

Logging-in does not necessarily mean giving tracking consent

While there are good specific reasons for clients to register when a user has logged in, it should not be seen as a proxy for a tracking consent signal.
One can login to a site and still not expect to be tracked, while on some sites wish to be tracked without having to login.
A user can register tracking consent, after being validly informed of the specific ways and purposes they would be tracked on a particular site, by clicking on a browser chrome UI element, or perhaps from a permissions API request (properly frequency limited by the browser). In Europe this is not only legally required but it becoming a well understood facility on many sites.

There still needs to be a browser mediated tracking consent signal, to be considered by browsers independently from the isLoggedIn signal.

Status of specification?

This is now defined in FedCM, https://fedidcg.github.io/FedCM/#login-status-javascript - should the (empty?) login-status.bs be removed?

Browser rules for a 'proper' login flow

In the section on abuse prevention, https://github.com/privacycg/is-logged-in#defending-against-abuse, WebAuthN and passwords are mentioned as the primary authentication means.

However, many more ways currently exist to allow a user to authenticate, including e.g certificates, 2FA not being webAuthN, or for example something like Windows Integrated Authentication. For many of these login flows, the browser is agnostic. In the proposal however, it is described browsers should become aware of what a 'proper' login is using 'rules that the browser can check'.

This may raise some challenges:

How many of such rules would any given browser have to know to support the multitude of (existing) authN methods?
How eager will browser vendors be to implement and support a potentially unlimited set of 'proper' login flows?
What would be an open, scalable yet also secure way to deal with this without becoming totally depended on the browser vendors? Will this need an (independent) body that evaluates and accreditates 'proper' login flows?
How can a novel authN method/standard gain traction if it is not supported (yet) in any browser - this may become a chicken/egg problem.
Or is it envisioned such login flows would need specific browser plugins each and every time? If so, does that not simply move the problem of abuse prevention?

Don't refer to cookies as legacy (yet)

This issue is ported from WebKit/explainers#39.

I don't think any browser has shipped HTTP State Tokens yet, so it seems premature to assume it's the default or to call cookies legacy.

Browsers explicitly knowing usernames a privacy regression?

The issue is from WebKit/explainers#32.

Browser privacy
This standard could actually mean that browsers know things about users that they didn't before, as an example, a username. Which may be reused across websites. As many browsers are built by commercial parties with interests in other sectors (cough....ad tech), I think it would at least be honest to mention or discuss the other side of the privacy coin.

How to make sure sites accurately report that the user is logged out?

This issue is ported from WebKit/explainers#35.

When the user gets logged out using site UI, how do we incentivize the site to accurately report that?

Consider making the name of the auth cookie or state token be mandatory

This issue was ported from WebKit/explainers#41.

If logged in state follows the expiration of a cookie or state token, then isn't it necessary to provide the name? There doesn't seem to be a mandatory parameter for it.

Two notes here:

This is only valid for HTTP State Tokens if more than one token is allowed per origin/site and such tokens have names.
The whole name doesn't necessarily have to be formalized if a specific prefix, attribute, or suffix is used. But something unique to the token/cookie needs to be formalized which is the core of this issue.

Handling server-side or out-of-band logouts

This issue was ported from WebKit/explainers#42.

Sometimes a user may be logged out of all devices/browsers due to some sort of server-side action. For example, this may happen due to too many failed login attempts, suspicious account activity, or a known password breach sending all users to a mandatory change password flow. How can the browser know about this?

One note: From a website perspective, this is no different than today. Tokens carrying authentication info may be set in an arbitrary number of browsers and apps and then an event in another place invalidates all those tokens. However, the browser may be communicating a logged in state to the user which is actually not true. I believe that is the issue discussed here.

Support for federated logins, or the ability to transfer IsLoggedIn

Porting to this repo; @johnwilander wrote:

Back in the original explainer, we explored an idea on how to support federated logins (logging in to one website with an account from another website that is not part of the same organization, as opposed to single sign-on which is about the same organization). This is what was said there:

Some websites allow the user to use an existing account with a federated login provider to
bootstrap a new local user account and subsequently log in. The IsLoggedIn API needs to
support such logins.

First, the federated login provider needs to call the API on its side, possibly after the
user has clicked a “Log in with X” button:

navigator.initiateLoggedInFederated(destination: secure origin) –> Promise<void>

For the promise to resolve, the user needs to already have the IsLoggedIn status set for
the federated login provider, i.e. the user needs to be logged in to the provider first.

Then the destination website has to call the API on its side:

   navigator.setLoggedInFederated(
      loginProvider: secure origin,
      username,
      credentialTokenType,
      optionalParams { }
   ) –> Promise<void>

The promise would only resolve if the loginProvider had recently called setLoggedInFederated() for this destination website.

What this comes down to is the capability to set IsLoggedIn on DependingSite by taking the user through specific steps on IdentityProviderSite. This would allow IdentityProviderSite to "transfer the ability to set IsLoggedIn" to DependingSite without there having to be e.g. a login form on SiteA.

We should discuss this opportunity without being tied to the original proposal quoted above. The important part is to explore how to support such a transfer capability.

Support "Remember me" functionality

This issue was ported from WebKit/explainers#38.

Many websites have an option to remember certain things, typically the username, even after the user logs out (whether explicitly or via timeout). If setLoggedOut immediately clears all first party state (does it? this isn't really explained in the explainer yet), then these features likely can't work. Do we need a provision for them?

advice/hooks for other login helper APIs to change login status

Give conditions and/or an API for any other API (fedcm, credential management, webauthn/passkey, maybe even Basic HTTP auth) that a browser might use to help the user log in to change Login Status.

In particular, needs:

confirmation from the site that the user did successfully log in,
username/identifier, and
a way/link for the user to log out.

And then either a method to call, or just a reference in the spec to how login status should be changed.

(Prompted by #44, but applies beyond fedcm.)

Potential requirement to have JS turned on to log in users to a site

It doesn't seem like this is discussed in the spec as a potential issue, but it seems that the call to navigator.setLoggedIn requires JS, this is a new requirement and would break any site that chooses not to have JS on authentication pages or anyway breaks navigation for any browser using extensions such as NoScript which are pretty popular as of recent.

Consider changing the name of the spec to better convey purpose, align with conventions

The spec is currently called "IsLoggedIn". This is odd for a couple of reasons:
(1) Web standards are not usually named after a single API entry point they provide.
(2) Web standard names are usually either an acronym or separate words, not words run together (with occasional exceptions for "Web" as a prefix)
(3) isLoggedIn isn't even the most relevant entry point. That would be the one where the page tells the browser that the user is logged in, not the one where it asks the browser whether the user is logged in. Pages don't need to ask, they already know. The primary purpose of the spec is for them to share that information.

I'd propose a name like "Login State API" or "Login Status API" to align with web standard naming conventions and better convey the overall purpose of this spec.

Consider renaming API entry points to align with conventions, better convey purpose

This is a few separate points about naming, they seemed better reported together, but I'd be willing to split the issue.

setLoggedIn sounds like a setter that would take a boolean, but it's not. You could imagine just calling it logIn, but this method doesn't actually perform a login; it just reports or records that status. That would suggest names like:

reportLogin
recordLogin
userLoggedIn

If a change like that is made, then it would make sense to also change setLoggedOut to reportLogout or recordLogout or the like.
Boolean getters in the DOM aren't given names starting with is, as is the convention in some other APIs. More common is plain adjective names like cancelable or disabled or complete (examples taken from DOM and HTML specs). On top of that, getter methods, particularly ones that return a promise, or not usually named as if they were an attribute. Rather, they're named like imperative verbs. For example, Permissions API has a method query to get the permission status. HTML has methods like convertToBlob and createImageBitmap. File System Access has getDirectory, getFile, and requestPermission (in fairness, also a counterexample: isSameEntry, but this is a comparison function that takes a parameter, not an async pseudo-getter.)

Overall, I'd recommend a name like getLoginState or checkLoginState. In code using promises, this reads pretty clean:

navigator.checkLoginState().then(state -> doSomething(state))

Whereas this (IMO) seems a bit awkward if you read it out loud:

navigator.isLoggedIn().then(state -> doSomething(state))

The methods should perhaps not be on window.navigator. The Navigator object is intended for info requests (and a few operations) that are truly global to the browser, affecting all sites/pages, rather than something scoped to a site. More local info/operations are generally put on another interface. For example, registration of custom elements is done via CustomElementRegistry, which is available as window.customElements, and this allows addition of new custom element definitions as well as retrieval of existing definitions. However, counterexample: Permissions API instead extends the Navigator object (as well as WorkerNavigator).

Use case: Prohibited password managers

This issue is intended to capture various cases of prohibited password managers and a discussion on how to support those with IsLoggedIn. They fall into the category of "unmanaged login flows," meaning the browser is explicitly kept out of managing the user's credentials.

The below use case is from WebKit/explainers#32.

FDA
Don't quote me on this part, but I want to at least mention it. I work in a company where some web properties are FDA relevant. One particular rule of FDA concerns password entry. If you'd take the most careful interpretation of that rule, conclusion is that password management tools are disallowed. The user has to type the password themselves.

This could actually be the wrong interpretation of the rule, I don't know, not an expert. But yes, this means the escape hatch may be needed. And preferably one without a new code change, because of compat reasons.

I dug up the relevant section:
Link

Consider renaming `setLoggedIn` and `setLoggedOut`

This issue is ported from WebKit/explainers#37.

setLoggedIn is a bit of an awkward name, as is setLoggedOut. What if they were called logIn and logOut? It's a little weird, since they don't actually perform the log in action, they just report it, but I think the names still work.

Auto-complete of second factors such as SMS codes should be consider browser mediated

In addition to the use of WebAuthn or a password manager, auto-complete of an SMS code may also be a trustworthy signal of the user logging in and should be included in the browser mediated category.

Why expose IsLoggedIn state directly?

This issue was ported from WebKit/explainers#44.

What is the benefit to an application in knowing the value of isLoggedIn? My impression is that there's little to no benefit in having that data exposed - the real value here is in two separate pieces:

Setting state lifetimes based on some more interesting parameters. You have enumerated a possible set.
Telling the browser that it's okay (or advisable or desired) to destroy state - logout.
Should we instead separate those two and not expose the isLoggedIn state directly?

What does logout mean in a federated context?

The proposal describes how federated login should work (https://github.com/privacycg/is-logged-in#federated-logins) and how the federated login provider needs to call the API as part of the login to the destination website.
What is however the expected behavior of both entities upon logout?

Should logout for one site remain 'local' to the current destination website or should that trigger 'global' logout at the federated login provider for all sites the user has recently logged in?
The former scenario may create a false sense of security for the user, as it may seem logout was done, but pressing login again may trigger (automatic) re-authN at the federated login provider a the user may still bel authenticated there.
The latter might create havoc if users get logged out of all site the currently have logged into.
Also, how would such a feature interplay with Single Sign-on capabilities of a the federated login provider?

How to notice when the user is logged out due to a timeout?

This issue is ported from WebKit/explainers#36.

Users may sometimes get logged out due to a timeout. Perhaps this can be the time limit on their login cookie, after which we infer a logout.

Concurrent logins support for `navigator.isLoggedIn` method.

Hi.
navigator.setLoggedOut(optionalUsername) shows that we might want to support concurrent logins on the same website.
Maybe It worth to add optionalUsername as an argument to navigator.isLoggedIn() –> Promise<bool> then?

Support multi-login and multiple user profiles

The user may have multiple accounts for one website, multiple users may be using the same browser to log in to a specific website (shared device case), and some websites allow multiple concurrent logins with fast profile switching. In the case of multiple concurrent logins, there may be a dominant or operating account among them.

We should try to support these use cases.

If the username parameter is the key under which all other state hangs, it means it really needs to be the site-unique username for the user and not just a display name. We may resolve this with a parameter for both display name and site-unique user name and browsers would have to make sure a multi user case with duplicate display names doesn't get confusing. One way of solving that is to only show the display name if it's unique for this site in this browser, otherwise show the site-unique username. When I say "show," I'm not talking about something specified by this spec but something browsers may build such as an IsLoggedIn status pill in the URL bar.

How to prevent bad-faith login claims?

This issue is ported from WebKit/explainers#34.

To expand on this a bit: If being logged in gives a site extra storage powers, then clearly they'll be incentivized to say the user is logged in as much as possible. We can try to link permission to call this API to browser-observable login actions (such as using WebAuthN, or user autofilling a password field, followed by some sort of submission of that form) but it might be tricky to prevent evasion.

Cater for existing logins, a.k.a. upgrade to IsLoggedIn

Once browsers ship this API, there will be a set of existing login sessions. Ideally those websites shouldn't have to re-authenticate the user to get the IsLoggedIn bit set. There needs to be a path to "upgrade to IsLoggedIn."

Could Site Engagement Serve the Same Purpose?

This has been brought up a couple of times. Chrome uses something called Site Engagement to understand which websites the user uses a lot. Could that signal be used to address the concerns about "logged in by default" and storage space?

One potential problem is that Site Engagement scores are neither accessible to websites nor possible to "set." It's an opaque thing from a developer perspective.

Replacing IsLoggedIn with something like Site Engagement also removes other possible use cases for IsLoggedIn such as helping users understand where they are logged in or allowing users to delete website data except where they are logged in.

Support Account Chooser: IDPs that support multiple users logged in at the same time

Many IDPs allow multiple users to be logged in at the same time or allow multiple different users to be logged in from the same browser (even at different times). You see this experience when logging into Google and many other sites. Today, this state is managed via local storage so that the IDP can display users who are either currently logged in or have logged in from this browser in the past. This is a must better user experience when the user wants to login again.

Is this in scope of IsLoggedIn? and if not, how does a logout event affect this data?

Should FedCM use the Login Status API?

TL;DR; this is a proposal to use navigator.recordLogin() (rather than IdentityProvider.recordLogin()) to help raise the FedCM privacy properties

FedCM has been working on the IdP Sign-in Status API (explainer and PR), which we believe to be a sub/narrow case of the more general Login Status API.

Over the course of its development, we heard from Mozilla that they'd like to see the IdP Sign-in Status API reconciled with the Login Status API, which I think is something that Safari would be generally supportive of based on what we discussed at TPAC2022.

Currently, the IdP Sign-in Status API is exposed as IdentityProvider.recordLogin() (and using recordLogin() was a deliberate choice to get us closer to the Login Status API), and I think Mozilla is suggesting that we use navigator.recordLogin() (so that it is effectively reconciled with the Login Status API as the same API).

The suggestion makes sense to me overall.

So, effectively, the proposal is to use navigator.recordLogin() instead of IdentityProvider.recordLogin() and to figure out how the specs refer to each other.

How does this sound, directionally speaking, to you?

PS A few (solvable, IMO) wrinkles:

This is a proposal to use the Login Status API in this very strict and narrow way for FedCM specifically (with well defined semantics/consequences in the FedCM flow specifically), not the more broad proposal that was made in the explainer (with undefined semantics/consequences). We would need to work together to be more precise in the explainer as well as spec text (on the specific parts that are going be effectively used by multiple implementations).
The IdP Sign-in Status API has only implications / consequences to FedCM, so we are worried about any random website calling it and writing something to browser storage that is not meaningful. So, we'd like to add some indication, e.g. navigator.recordLogin({idp: true}) that indicates that this is an user logging-in to an identity provider rather than any arbitrary website.
We heard from developers that a lot of their login systems use HTTP 302s rather than JS, so we also introduced a header called "IdP-SignIn-Status: action=signin" and "IdP-SignIn-Status: action=signout-all" which is intended to be equivalent to the JS API. We would also reframe it to be something like "SignIn-Status: action=signin, idp=true" so that it can be used by regular websites too in the future.
The signature of recordLogin() isn't exactly what we need at the moment (e.g. it takes a username), so we'd likely need to narrow it down.
We called the logout function recordLogoutAll(), to handle cases where multiple-accounts are used.

Use Case: Updating OS-integrated surfaces

When it comes to Notifications (and, eventually, Widgets) that are orchestrated by a Service Worker, some of those surfaces will be predicated on authentication.

For instance, a direct message that shows up as a push notification should probably only be shown if that user remains logged in to the service that delivered it. So if, for example, a Twitter DM was delivered to me as a Push, but then I log out of the Twitter PWA, the Service Worker should be informed of the logout event in order to know it should remove that push notification from the system.

As we begin to figure out how PWAs participate in a host OS through Widgets, it becomes similarly important to tie auth to those surfaces as well. Our current explorations are built on the Notification management concept, so any work we do to enable Service Workers to be auth-aware will benefit Widgets as well.

In order to make this a reality, it feels like 2 things become necessary:

A means of communicating events related to authentication from host process to the Service Worker. This could be done by developers through postMessage() but we might also consider defining an event ("authchange"?) or set of events ("login" and "logout") that a Service Worker could listen for.
A means of tracking which surfaces (notifications, widgets) are auth-tied. This could certainly be done by developers on their own (and tracked in IndexedDB, for example) or it could be a flag we set on Notification and Widget objects ("requires_auth"?) so that a Service Worker could quickly iterate active Notifications, destroying ones that should not longer be seen, and Widgets to update them to prompt login before they can be used.

Anyway, would love y’all’s thoughts on this.

Privileges that come with IsLoggedIn may push sites to mandate login

The privileges that may be associated with IsLoggedIn may incentivize websites to mandate logins. Such a result may not be beneficial for user privacy since PII is often involved in logging in. This has been discussed a few times and is an open issue.

Potential use of First Party Sets for Single Sign-On

IsLoggedIn is meant to let the browser reason about where the user is logged in. A special case of that is single sign-on (SSO) within one organization. Issue 28 on First Party Sets tracks the addition of a mandatory purpose string for each domain in a set. One such purpose can be SSO.

A potential integration between IsLoggedIn and First Party Sets could be the SSO site telling the browser that "IsLoggedIn set for my domain should mean IsLoggedIn for these other domains in my set." The browser could then reason about all of them, both for logged in and logged out state, and apply whatever other policy it has for the whole set as being logged in. Browser UI could show the user as logged in to the set and even highlight the domain that carries the SSO main state.