Open judielaine opened 1 year ago
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.
"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.
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.