Allow RPs to selectively request attributes of the user's profile

[cbiesinger]

(this has been split out of w3c-fedid/FedCM#477 / #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)

[cbiesinger]

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 fields parameter
• Fields that the browser disclosed to the user are sent in a disclosure_shown_for parameter.

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,picture

If 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.

[cbiesinger]

We have now substantially reworked the proposal, with the primary goal of making it less OAuth-scope specific and the secondary goal of allowing future customizations of the UI such as not asking for email or asking for a phone number instead.

I would love to hear thoughts on the new proposal! It is in the updated comment above.

[elf-pavlik]

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 (w3c-fedid/FedCM#435) 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).

I see that the Contact Picker API is already on the REC track: https://www.w3.org/TR/contact-picker/

Isn't some alignment between user information and contact information helpful? Offering similar UX for disclosing common properties and consistent DX for handling that information would be a plus.

[chad-cole]

I am interested in the Fields API, as is my team at Shopify. Is there anything we can do to help move this forward?

---

I am new to the FedCM community, apologies if this is not the right place to register interest. If not a pointer would be greatly appreciated!

[npm1]

Hey Chad, actually there is! This API is currently on Origin Trials in Chrome. See https://developers.google.com/privacy-sandbox/blog/fedcm-chrome-126-updates. So you can try it out yourself but you can also test it out on real users if you deploy FedCM and use the OT, and provide feedback that way. We also have https://groups.google.com/g/fedcm-developer-newsletter for people interested in FedCM updates in Chrome. Feel free to comment here with questions.

[samuelgoto]

Just cross posting from a related discussion that's happening in a different repo, to introduce a username field:

privacysandbox/privacy-sandbox-dev-support#379 (comment)

[samuelgoto]

Here are a few fields that we heard in the past that may be useful to start from:

• name
• email
• picture
• username (based on this)
• phoneNumber (based on this)

And allow any combination of these values, e.g. ["name", "email"] or ["name", "picture", "username"].

[TallTed]

Any time fields like these are being considered, it's worth another review of the Awesome Falsehoods lists.

Many of the potential downfalls reavealed there would be avoided by the "any combination of n fields" idea, but these can still be helpful in making each field less problematic in itself.

[gioele-antoci]

Joel from Shopify here! phoneNumber in particular would be HUGE for us! +1