Use generic names for the header and JS API

proposals/idp-sign-in-status-api.md

@@ -40,8 +40,8 @@ settings page allowing the user to disable certain IDPs for use with FedCM.
 ### Headers
 
 ```
-IdP-SignIn-Status: action=signin
-IdP-SignIn-Status: action=signout-all
+SignIn-Status: action=signin; type=idp
+SignIn-Status: action=signout-all; type=idp
 ```
 
 These headers can be sent on the toplevel load as well as subresources such as
@@ -53,23 +53,31 @@ was the last/only account getting signed out.
 
 ### JS API
 
-An IdP can alternatively call the IdP Sign-in Status API via JS calls through
-the static functions `IdentityProvider.login()` and
-`IdentityProvider.logout()`. These are to be called from the IDP's origin, and
-marks the current origin as signed in or signed out.
+```idl
+
+dictionary SigninStatusOptions {
+  boolean idp = false;
+};
 
+partial interface Navigator {
+  Promise<void> recordSignedIn(optional SigninStatusOptions options);
+  Promise<void> recordSignedOut(optional SigninStatusOptions options);
+};
 ```
+
+An IdP can alternatively call the IdP Sign-in Status API via JS calls through
+the static functions `navigator.recordSignedIn({idp: true})` and
+`navigator.recordSignedOut({idp: true})`. These are to be called from the IDP's
+origin, and marks the current origin as signed in or signed out.
+
+```idl
 [Exposed=Window]
 interface IdentityProvider {
-  static void login();
-  static void logout();
-
   static void close();
 }
 ```
 
-
-In addition, a `close()` function is provided to signal to the browser that the
+In addition, a `IdentityProvider.close()` function is provided to signal to the browser that the
 signin flow is finished. The reason for this function in addition to the header
 is that even when the user is already logged in, the signin flow may not be
 finished yet; for example, an IDP may want to prompt the user to verify their
@@ -153,15 +161,15 @@ We could instead or in addition have allowed notifying the user agent of
 individual accounts being signed in/out, such as:
 
 ```
-IdP-SignIn-Status: action=signin; count=2
-IdP-SignIn-Status: action=signout; new-count=1
+SignIn-Status: action=signin; count=2; type=idp
+SignIn-Status: action=signout; new-count=1; type=idp
 ```
 
 Or
 
 ```
-IdP-SignIn-Status: action=signin; [email protected]
-IdP-SignIn-Status: action=signout; [email protected]
+SignIn-Status: action=signin; [email protected]; type=idp
+SignIn-Status: action=signout; [email protected]; type=idp
 ```
 
 However, we decided to go with the simpler syntax because we do not currently
@@ -177,4 +185,7 @@ whether no accounts remain after this signout action.
 
 We are also considering with Safari and Firefox how this API relates to the Login Status API [here](https://github.com/privacycg/is-logged-in/issues/53).
 
+In this proposal, we are using generic header and JS function names so that the same API and
+headers can be used also for is-logged-in while recording the optional type (i.e. is this
+an IDP or not).