Allow adding/removing/expiring individual accounts

[ekovac]

We received some feedback that ideally, navigator.login.setStatus should allow IdPs to set individual expiration durations for each account. Additionally, some IdPs may want to add/remove accounts individually to respond to changes in the user's signin status when using multiple accounts with a single IdP.

---

Making "expiration" an account-level field seems reasonable to me, as it wouldn't drastically increase the complexity of the API, nor of implementation in the browser. To accomplish this we could add an "expiration" field to the account entries passed into navigator.login.setStatus.:

navigator.login.setStatus("logged-in", {
	accounts: [{id: "1", name: "John Doe", expiration: 86_400_000}],
});

The biggest drawback here is that multiple accounts with the same expiration TTL would require specifying redundant values. I think this is a fairly minor problem, as the ergonomics of hand-written calls to set multiple login statuses aren't a high priority. More likely this array would be populated from some API endpoint or cookie contents, and then passed into navigator.login.setStatus.

const accounts = await fetch("https://idp.example/fedcm/accounts_for_status");
// Response contains:
// [{id: "1", name: "John Doe", expiration: 86_400_000}, 
//  {id: "2", name: "John The Gamer", expiration: 86_400_000}]

navigator.login.setStatus("logged-in", {accounts});

If the ergonomics are still a concern, we could retain the current expiration field on the options object, and just let individual account entries override that value.

---

Adding/removing individual accounts might also be useful to IdPs, but raises more questions.

As a straw proposal to get things started: Overloading the existing navigator.login.setStatus API for this would probably be cumbersome. "Set" generally implies replacing the existing value. Expressing the intent to remove or add an account instead of replacing the entire account list via another property in the options object for setStatus is probably not acceptable. Instead, we'd probably want to add two new methods to navigator.login:

// "logged-in" is implicit here.
navigator.login.addStatusAccount({id: "1", name: "John Doe", expiration: 86_400_000});
navigator.login.addStatusAccount({id: "2", name: "John The Gamer", expiration: 86_400_000});

navigator.login.removeStatusAccount({id: "2"});

// Now, only the account with id "1" remains in the accounts list for this IdP's origin.

---

The question for both of these changes is whether the added complexity is necessary. I'm on the fence about it, and while I think there's a path forward for both of these changes, I think both can be added later without significant backward-compatibility issues for the existing design.