cbiesinger
commented
5 months ago Proposal
This is a proposal to allow an RP to specify an additional request parameter to select which standard attributes of the user's account are used in the selective disclosure dialog. For example, it allows RPs to skip the permission dialog altogether (but not the account chooser) to use a pop-up window instead, as well as, in the future, selectively request attributes (e.g. skipping email addresses, or asking for language preferences or phone numbers).
partial dictionary IdentityProviderConfig {
// A list of strings that represent what prompt the browser should show
// For now "email", "name" and "picture" are supported as described below.
sequence<USVString> fields;
};An RP could use them like this:
let {token} = await navigator.credentials.get({
identity: {
providers: [{
// A newly introduced "fields" attribute, a list of strings
// Defaults to ["name", "email", "picture"], which is what
// currently is asked of the user.
// When [] is used, the selective disclosure prompt is
// skipped altogether.
fields: [],
clientId: "1234",
nonce: "234234",
configURL: "https://idp.example/fedcm.json",
},
}
});This parameter is sent to the ID assertion endpoint as follows (that is, they will only be shared with the IdP after user permission):
- All RP specified fields are sent in a
fieldsparameter - Fields that the browser disclosed to the user are sent in a
disclosure_shown_forparameter.
The browser uses it to disclose to the user the fields that are being requested by the RP. If an empty array is specified, the browser skips the disclosure dialog, since nothing is being requested out of the user's standard profile. It is the IdP's responsibility to only share the requested pieces of information, rely on previously gathered permissions or gather additional permission through the Params API and the Continuation API.
Because permissions are not requested for returning users, this new parameter has no impact on the UI for such users, and disclosure_shown_for will be sent with an empty string.
For example, the ID assertion request body might look like this:
POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity
account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=true&fields=email,name,picture&disclosure_shown_for=email,name,pictureIf necessary, the IdP can use the Params API and the Continuation API to gather the user's permission for additional fields.
Forwards Compatibility
While we expect the Continuation API to cover most extensibility needs, we also expect that there is a subset of well-known attributes that the user agent would be able to mediate constructively (e.g. lower friction than pop-up windows, UX consistency across IdPs). Beyond name/email/picture which is currently supported, some of the most commonly asked extensions are allowing RPs to request for the user's phone number (as opposed to email addresses) or the user's language preferences. It is not clear where we could go from there, but we expect a subset of the OIDC's Standard Claims or HTML's autocomplete to be things that the browser could potentially mediate in a constructive way (e.g. organization, country, websites).
In order not to break older browsers when new fields are added to the spec, we suggest the following semantics:
- The browser ignores fields that it does not understand
- The browser sends only the fields that it did understand and prompted for to the IDP in the fields parameter
- If, based on the fields that were sent, the IdP needs to gather additional permission, it can do so using the continue_on parameter
For now, we expect that browsers only support prompting for ["name", "email", "picture"]. That is, if the array contains one or two of, but not all three of "name", "email", and "picture", we expect the promise to be rejected immediately. RPs/IdPs which want to prompt for a subset of these "standard" fields will have to use an empty array and prompt using the Continuation API. In the future, we may support other sets of fields, such as only name and picture, or name, picture and phone number. We expect to add an IdP-side opt-in mechanism to specific supported fields to the configURL at that point in time.
A future version of the spec might allow a user to selectively permit sharing some but not all of the requested fields. If this happens, we expect to add another parameter that would contain the fields that the user has disallowed.
elf-pavlik
chad-cole
npm1
samuelgoto
TallTed
gioele-antoci
(this has been split out of w3c-fedid/FedCM#477 / w3c-fedid/continuation#2)
Currently, the FedCM dialog is composed of two parts: (a) account choosing and (b) a selective disclosure prompt. The latter, is used to disclose to the user which attributes of the their profile are being requested by the RP (currently hardcoded to name/email/picture).
Sometimes, however, the RP needs more than the user's basic profile (e.g. the user's phone number), less (e.g. not requiring email addresses, e.g. w3c-fedid/FedCM#317 and w3c-fedid/FedCM#242 ), or not at all (e.g. access to the user's storage access, but not their profile), so the current UI doesn't represent the permission that the IdP needs to gather.
Currently, there is no way that the RP can use FedCM and have control over what they actually need from the IdP.
(https://fedidcg.github.io/FedCM/#request-permission-signup)