-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Context (allow customization in the title) #456
Comments
Non goalsIt 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. Use CasesThere 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”). MocksThe API doesn’t make any visual UI structural changes other than the strings that we use. Currently, we have:
And the proposal is to introduce 3 context modes (in addition to the default, "signin"):
Examplesconst {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",
}],
}
}); IDLThe specific way in which we propose to extend the FedCM API is the following:
Privacy ConsiderationsThere are no privacy concerns introduced with this feature. Security ConsiderationsThe 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. Open Questions
|
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. |
Sounds reasonable to me.
@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.
The text was updated successfully, but these errors were encountered: