Remove language referring to sign-up and sign-in, amplify in browser state machine

[judielaine]

"Sign-up" and "Sign-in" are replying party concepts that are not being addressed in this API. When the spec refers to "[t]he Sign-up and Sign-in APIs" it immediately clarifies that the relying party does not distinguish in it's interaction with the browser APIs. This seems to indicate that there's some recognition that there is a poor word choice in what are two different states the browser should track.

The Sign-up and Sign-in APIs are used by the Relying Partys to ask the browser to intermediate the relationship with the Identity Provider and the provisioning of a token.

NOTE: The Relying Party makes no delineation between Sign-up and Sign-in, but rather calls the same API indistinguishably.

Instead, i suggest removing the terms all together, and replacing with "Auth request API" or "Auth registration API" (or something else) and continuing with the states of "registered or unregistered"

Relying party use cases confused by this:

Preprovisioned accounts RPs may preprovision accounts from the organization that is responsible for the IdP. These RPs would maintain they offer no "Sign up" capability. However, the flow for IdP registration and subsequent requests is still valid.

Authorization only accounts RPs may use auth flows, like OAuth's Auth code request or SAML's Anonymous Authorization pattern, for access control but NOT to establish a relationship with user. These RPs would not want any "Sign up" capability at all. However, the flow for IdP registration and subsequent requests is still valid.

[judielaine]

Reviewing the Use cases, to 1.1.1. Sign-up i suggest a third paragraph.

Note that an RP may have pre-provisioned accounts or may only be requesting authorization from an IdP. In these cases the RP's implementation is not required to express any account creation text to the user. However, the user will be required by the browser to express consent to use the selected IdP with the RP.