Closed npm1 closed 1 year ago
It is a non goal to come up with something that is infinitely extensible / expressive. It is ok if we end up with a limited enumeration of contexts in which we expect the prompt to be used.
There are some known use cases that we heard in the past from developers:
Here are a few examples [1, 2] used by Facebook Login (“login with” or ”continue with”) and Google Sign-in (“sign-in with”, “sign-up with”, “continue with” and “use with”).
The API doesn’t make any visual UI structural changes other than the strings that we use. Currently, we have:
Use Case | String |
---|---|
Status Quo | Sign in to $RP with $IDP |
And the proposal is to introduce 3 context modes (in addition to the default, "signin"):
Use Case | String |
---|---|
Sign-in | Sign in to $RP with $IDP (default) |
Sign-up | Sign up to $RP with $IDP |
Continue | Continue to $RP with $IDP |
Use | Use $RP with $IDP. |
const {token} = await navigator.credentials.get({
identity: {
// “signin” is the default, “signup”, “use” and “continue” can also be used
context: "signup",
providers: [{
configURL: "https://idp.example/fedcm.json",
clientId: "1234",
}],
}
});
The specific way in which we propose to extend the FedCM API is the following:
Extensions to FederatedCredential
partial dictionary IdentityCredentialRequestOptions {
// ...
// A querying language that allows an RP to ask what it wants from the issuers.
IdentityCredentialRequestOptionsContext context;
};
enum IdentityCredentialRequestOptionsContext {
“signin”, “signup”, “use”, “continue”
};
There are no privacy concerns introduced with this feature.
The RP being given the opportunity to modify user agent UI needs to be treated carefully. To mitigate the risk, the API provides an enum of possible values that the RP can pass along to the user agent. In addition, the API does not dictate how exactly the user agent needs to include those values in their UI, which gives the user agent flexibility to use the context as it sees fit. For instance, if the user agent detects an RP that is incorrectly declaring context in some way, it may disable the FedCM API on that RP altogether, or it may simply ignore the RP context provided.
This would be in line with Seamless Access practices, we've done extensive testing as we are in the field that one can be granted access to the paper but not actually signed into the local site.
We currently use the word "Access" as in "Access through $name of institute". As FedCM does not persee imply that one is signing into a service, we would like to be able to continue using this nomenclature.
For requests for new context types, let's use a separate issue. Closing this one as the PR has landed with the initial context values.
"Access through $name of institute".
Sounds reasonable to me.
For requests for new context types, let's use a separate issue. Closing this one as the PR has landed with the initial context values.
@Bojhan can you kick off a new github issue and describe a bit more the use case and uses? This seems like a reasonable addition, but we could use a bit more context.
Currently, Chrome's FedCM prompt assumes that the user is inside a sign-in flow, so uses language to match that:
Sign-in to rp.example with idp.example
The prompt is awkward when used inside of other flows, such as signing-up or unlocking content (e.g. a scholarly article) based on federated identity (e.g. a university student). While a user agent can choose a title different from Chrome's, the RP has no way to provide some hint about what type of flow is being presented to the user, so the user agent cannot customize the title.