Contact Picker API

W3C Working Draft,

More details about this document
This version:
https://www.w3.org/TR/2024/WD-contact-picker-20240227/
Latest published version:
https://www.w3.org/TR/contact-picker/
Editor's Draft:
https://w3c.github.io/contact-picker/
Previous Versions:
History:
https://www.w3.org/standards/history/contact-picker/
Feedback:
public-device-apis@w3.org with subject line “[contact-picker] … message topic …” (archives)
GitHub
Editor:
(Google)
Former Editor:
(Google)

Abstract

An API to give one-off access to a user’s contact information with full control over the shared data.

Status of this document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the Devices and Sensors Working Group and the Web Applications Working Group as a Working Draft using the Recommendation track. This document is intended to become a W3C Recommendation.

If you wish to make comments regarding this document, please send them to public-device-apis@w3.org (subscribe, archives). When sending e-mail, please put the text “contact-picker” in the subject, preferably like this: “[contact-picker] …summary of comment…”. All comments are welcome.

Publication as a Working Draft does not imply endorsement by W3C and its Members. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by groups operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures (Devices and Sensors) and a public list of any patent disclosures (Web Applications) made in connection with the deliverables of each group; these pages also include instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 03 November 2023 W3C Process Document.

1. Introduction

Contact pickers are frequently seen in various desktop and native mobile applications for a variety of use cases. This specification defines an API to bring contact pickers to the web, which will enable new use cases for web apps, such as:

The contact picker model was chosen to give full control to users over the shared data, allowing users to choose exactly which contacts to provide to the website. The contact picker model gives websites one-off access to a user’s contacts, meaning developers have to request access to the user’s contacts every time they need it. This differs from some native contact APIs, but is necessary for ensuring users' contacts are not accessed without their knowledge and explicit consent.

1.1. Examples

Requesting contacts as a result of a user click.
selectRecipientsButton.addEventListener('click', async () => {
  const contacts = await navigator.contacts.select(['name', 'email'], {multiple: true});

  if (!contacts.length) {
    // No contacts were selected in the picker.
    return;
  }

  // Use the names and e-mail addresses in |contacts| to populate the
  // recipients field in the website’s UI.
  populateRecipients(contacts);
});

In the above example selectRecipientsButton is a HTMLButtonElement, and populateRecipients is a developer-defined function.

Requesting an address to deliver a gift to.
selectRecipientButton.addEventListener('click', async () => {

  // We are unsure if addresses are supported, or can be provided by the browser.
  if ((await navigator.contacts.getProperties()).includes('address')) {
    const contacts = await navigator.contacts.select(['address']);

    if (!contacts.length) {
      // No contacts were selected in the picker.
      return;
    }

    // length is 1 since we didn’t request multiple contacts.
    sendGiftToAddress(contacts[0].address);
  }

 // Fallback to a form. 
});

In the above example selectRecipientButton is a HTMLButtonElement, and sendGiftToAddress is a developer-defined function.

Requesting a name and an icon.
selectRecipientButton.addEventListener('click', async () => {

  // We are unsure if icons are supported, or can be provided by the browser.
  if ((await navigator.contacts.getProperties()).includes('icon')) {
    const contacts = await navigator.contacts.select(['name', 'icon']);

    if (!contacts.length) {
      // No contacts were selected in the picker.
      return;
    }

    if (!contacts[0].name.length || !contacts[0].icon.length) {
      // Info not found. Use fallback.
      return;
    }

    // We only need one name and one image.
    const name = contacts[0].name[0];
    const imgBlob = contacts[0].icon[0];

    // Display image.
    const url = URL.createObjectURL(imgBlob);
    imgContainer.onload = () => URL.revokeObjectURL(url);
    imgContainer.src = url;

    // Alternatively use a Bitmap.
    const imgBitmap = await createImageBitmap(imgBlob);

    // Upload icon.
    const response = await fetch('/contacticon', {method: 'POST', body: imgBlob});
  }
});

In the above example selectRecipientButton is a HTMLButtonElement, and imgContainer is a HTMLImageElement.

2. Privacy Considerations

Exposing contact information has a clear privacy impact, in terms of exposing PII of uninvolved parties. A picker model is enforced so that the user agent can offer a user experience that makes it clear what information is going to be shared with the website and when.

The following constraints are also enforced:

3. Realms

All platform objects are created in the this's relevant Realm unless otherwise specified.

4. Infrastructure

The contact picker task source is a task source.

To queue a contact picker task on an optional eventLoop (an event loop, defaulting to the caller’s this's relevant settings object's responsible event loop) with steps (steps), queue a task on eventLoop using the contact picker task source to run steps.

4.1. Physical address

A physical address consists of:

4.2. User contact

A user contact consists of:

A user contact contains data relating to a single user.

Note: The lists can be of different sizes, and entries with the same index don’t need to correspond to each other.

4.3. Contacts source

The contacts source is a service that provides the user’s contact information to the user agent.

A contacts source consists of:

Note: It is up to the user agent to choose the contacts source.

5. API Description

5.1. Extensions to Navigator

[Exposed=Window]
partial interface Navigator {
  [SecureContext, SameObject] readonly attribute ContactsManager contacts;
};
A Navigator has a contacts manager (a ContactsManager), initially a new ContactsManager.

The contacts attribute’s getter must return the this's contacts manager.

The browsing context has a contact picker is showing flag, initially unset.

5.2. ContactProperty

enum ContactProperty { "address", "email", "icon", "name", "tel" };

A ContactProperty is considered to be available if its associated user contact field can be accessed by the user agent.

"address"

Associated with user contact's addresses.

"email"

Associated with user contact's emails.

"icon"

Associated with user contact's icons.

"name"

Associated with user contact's names.

"tel"

Associated with user contact's numbers.

5.3. ContactAddress

[Exposed=Window]
interface ContactAddress {
  [Default] object toJSON();
  readonly attribute DOMString city;
  readonly attribute DOMString country;
  readonly attribute DOMString dependentLocality;
  readonly attribute DOMString organization;
  readonly attribute DOMString phone;
  readonly attribute DOMString postalCode;
  readonly attribute DOMString recipient;
  readonly attribute DOMString region;
  readonly attribute DOMString sortingCode;
  readonly attribute FrozenArray<DOMString> addressLine;
};

The ContactAddress interface represents a physical address.

A ContactAddress instance has:

The city attribute’s getter must return the this's address' city.

The country attribute’s getter must return the this's address' country.

The dependentLocality attribute’s getter must return the this's address' dependent locality.

The organization attribute’s getter must return the this's address' organization.

The phone attribute’s getter must return the this's address' phone number.

The postalCode attribute’s getter must return the this's address' postal code.

The recipient attribute’s getter must return the this's address' recipient.

The region attribute’s getter must return the this's address' region.

The sortingCode attribute’s getter must return the this's address' sorting code.

The addressLine attribute’s getter must return the this's address' address line.

5.4. ContactsManager

dictionary ContactInfo {
    sequence<ContactAddress> address;
    sequence<DOMString> email;
    sequence<Blob> icon;
    sequence<DOMString> name;
    sequence<DOMString> tel;
};

dictionary ContactsSelectOptions {
    boolean multiple = false;
};

[Exposed=Window, SecureContext]
interface ContactsManager {
    Promise<sequence<ContactProperty>> getProperties();
    Promise<sequence<ContactInfo>> select(sequence<ContactProperty> properties, optional ContactsSelectOptions options = {});
};

5.4.1. getProperties()

The getProperties() method, when invoked, runs these steps:
  1. Let promise be a new promise.

  2. Run the following steps in parallel:

    1. Resolve promise with contacts source's supported properties.

  3. Return promise.

5.4.2. select()

The select(properties, options) method, when invoked, runs these steps:
  1. Let relevantBrowsingContext be the this's relevant settings object's responsible browsing context.

  2. If relevantBrowsingContext is not a top-level browsing context, then return a promise rejected with an InvalidStateError DOMException.

  3. If the algorithm is not triggered by user activation then return a promise rejected with a SecurityError DOMException.

  4. If relevantBrowsingContext’s contact picker is showing flag is set then return a promise rejected with an InvalidStateError DOMException.

  5. If properties is empty, then return a promise rejected with a TypeError.

  6. For each property of properties:

    1. If contacts source's supported properties does not contain property, then return a promise rejected with a TypeError.

  7. Set relevantBrowsingContext’s contact picker is showing flag.

  8. Let promise be a new promise.

  9. Run the following steps in parallel:

    1. Let selectedContacts be be the result of launching a contact picker with optionsmultiple member and properties. If this fails, then:

      1. Return a promise rejected with an InvalidStateError DOMException.

      2. Unset relevantBrowsingContext’s contact picker is showing flag.

      3. Abort these steps.

    2. Unset relevantBrowsingContext’s contact picker is showing flag.

    3. Queue a contact picker task to run these steps:

      1. Let contacts be an empty list.

      2. For each selectedContact in selectedContacts:

        1. Let contact be a new ContactInfo with:

          address

          selectedContact’s addresses if properties contains "address", otherwise undefined.

          email

          selectedContact’s emails if properties contains "email", otherwise undefined.

          icon

          selectedContact’s icons if properties contains "icon", otherwise undefined.

          name

          selectedContact’s names if properties contains "name", otherwise undefined.

          tel

          selectedContact’s numbers if properties contains "tel", otherwise undefined.

        2. Append contact to contacts.

      3. Resolve promise with contacts.

  10. Return promise.

6. Contact Picker

To launch a contact picker with allowMultiple (a boolean), and properties (a list of DOMStrings), the user agent MUST present a user interface that follows these rules:
  • If presenting a user interface fails or accessing the contacts source's available contacts fails, then return failure.

  • The UI MUST prominently display the browsing context's origin.

  • The UI MUST make it clear which properties of the contacts are requested.

    NOTE: This information is derived from properties.

  • The UI SHOULD provide a way for users to opt out of sharing certain contact information.

    NOTE: If the user opts out, the appropriate user contact fields should be modified before returning the selected contacts. It should be indistinguishable from the returned user contacts whether the user opted out from sharing some information or if the information was not present to begin with.

  • The UI MUST make it clear which information will be shared.

  • The UI MUST provide a way to select individual contacts. If allowMultiple is false, only one contact should be pickable.

  • The UI MUST provide an option to cancel/return without sharing any contacts, in which case remove the UI and return an empty list.

  • The UI MUST provide an a way for users to indicate that they are done selecting, in which case remove the UI and return a list of the selected contacts as user contacts.

7. Acknowledgments

There has been multiple earlier attempts to standardize a Contacts API for the web and this API strives to learn from this rich history. Earlier attempts include Mozilla’s Contacts API, Contacts API W3C Member submission and standardization efforts by W3C Working Groups: Contacts API, Pick Contacts Intent, and Contacts Manager API. The Contact Picker API differs in its approach to privacy, which was the main emphasis of the API when it was designed. Unlike previous attempts which allow for perpetual access after granted permission, or include a vague privacy model, this spec enforces UI restrictions which give users full control over shared data and limit abuse. For example, a picker model is enforced where the user always acts as an intermediary of the shared contact info with full control every time contacts are requested. For more historical context, please refer to the Status of the Document sections of the earlier attempts.

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[FileAPI]
Marijn Kruisselbrink. File API. 6 February 2023. WD. URL: https://www.w3.org/TR/FileAPI/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[WEBIDL]
Edgar Chen; Timothy Gu. Web IDL Standard. Living Standard. URL: https://webidl.spec.whatwg.org/

Informative References

[E.164]
The international public telecommunication numbering plan. November 2010. Recommendation. URL: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-E.164-201011-I!!PDF-E&type=items
[ISO3166-1]
Codes for the representation of names of countries and their subdivisions — Part 1: Country code. August 2020. Published. URL: https://www.iso.org/standard/72482.html
[MIMESNIFF]
Gordon P. Hemsley. MIME Sniffing Standard. Living Standard. URL: https://mimesniff.spec.whatwg.org/

IDL Index

[Exposed=Window]
partial interface Navigator {
  [SecureContext, SameObject] readonly attribute ContactsManager contacts;
};

enum ContactProperty { "address", "email", "icon", "name", "tel" };

[Exposed=Window]
interface ContactAddress {
  [Default] object toJSON();
  readonly attribute DOMString city;
  readonly attribute DOMString country;
  readonly attribute DOMString dependentLocality;
  readonly attribute DOMString organization;
  readonly attribute DOMString phone;
  readonly attribute DOMString postalCode;
  readonly attribute DOMString recipient;
  readonly attribute DOMString region;
  readonly attribute DOMString sortingCode;
  readonly attribute FrozenArray<DOMString> addressLine;
};

dictionary ContactInfo {
    sequence<ContactAddress> address;
    sequence<DOMString> email;
    sequence<Blob> icon;
    sequence<DOMString> name;
    sequence<DOMString> tel;
};

dictionary ContactsSelectOptions {
    boolean multiple = false;
};

[Exposed=Window, SecureContext]
interface ContactsManager {
    Promise<sequence<ContactProperty>> getProperties();
    Promise<sequence<ContactInfo>> select(sequence<ContactProperty> properties, optional ContactsSelectOptions options = {});
};