cbiesinger
commented
6 months ago Proposal
We are proposing an optional “labels” attribute in the returned account list:
{
"accounts": [{
"id": "1234",
"given_name": "John",
"name": "John Doe",
"email": "john_doe@idp.example",
"picture": "https://idp.example/profile/123",
// New field:
"labels": ["type1", "type2"]
}]
}Similarly, the configURL can optionally specify a label that needs to match at least one of the labels in the list:
{
"accounts_endpoint": "accounts.py",
"client_metadata_endpoint": "client_metadata.py",
"id_assertion_endpoint": "token.py",
"login_url": "login.html",
// New field:
"accounts": {
include: "type1"
}
}Labels are strings. If the “labels” array or “include” field contains something that is not a string, it is ignored.
If no label is specified in the configURL, all accounts will be displayed in the FedCM account chooser. If no labels are specified for an account, it will only be displayed in the account chooser if the configURL also does not specify a label.
The requested label from the configURL will not be sent to the server and is purely used client-side.
If no account matches the requested label, we treat it the same as if no login_hint or domain_hint matches.
This is different from the login_hint/domain_hint attributes in that it provides a way to associate accounts with more generic, abstract groups, not constrained to domain-specific associations like a domain or login hint.
Note that this proposal depends on the proposal in #552
Alternatives considered
Change domain_hint and/or login_hint to an array in the navigator.credentials.get call
The way this would work is that the server would include a “fake” login hint or domain hint in the array it sends in the account list. The caller would specify the desired label in the call to navigator.credentials.get in addition to any “real” login or domain hint they need, and both/all have to match.
Advantages:
- No need to invent a new field for a similar purpose (account filtering)
- Does not rely on the support for multiple configURLs under an eTLD+1 (#552)
Disadvantages:
- Backwards compatibility complexity (need to accept either a string or an array for login/domain_hint)
- Have to specify the label in each caller instead of having it provided automatically through the config file
- Seems a bit of an abuse to use a login/domain_hint for something that is neither
Relax the limit of a single account endpoint
Allowing IDPs to have multiple (two) account endpoints under an eTLD+1 (#333) would solve this problem as well, however this provides an extra bit of entropy to the server that is undesirable from a privacy perspective.
Append a query parameter to the account endpoint
Based on some parameter to the FedCM call, we could append a query parameter to the accounts endpoint. As a strawman, if non-default scopes were requested, we would append ?has_scopes=1 when requesting the account list. From a privacy perspective, this is equivalent to the previous option; from a technical perspective this would be somewhat simpler but less flexible.
wseltzer
Some identity providers (IDPs) want to show different sets of accounts in different contexts. For example, some relying parties (RPs) may want to filter out certain account types such as minors.
The most straightforward way to do that is to allow IDPs to specify different account endpoint URLs for different contexts, but that has undesirable privacy properties (ie., the specific account endpoint URL would tell the IDP which subset of accounts is being queried by the client, which could provide the IDP with some information on which RP the user is currently on if specific account subsets were associated with specific sets of RPs, potentially impacting the user's privacy). Hence, this document proposes a way to filter accounts in a privacy-preserving way by filtering the accounts on the client side..