Managed Configuration API

Draft Community Group Report,

This version:
Issue Tracking:
(Google LLC)


This document defines a web platform API that enables developers to access administrator-set configuration on managed devices. Such API invaluable for such use cases as digital signage and device-centric personalization.

Status of this document

This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

1. Model

1.1. Managed devices

The API is presumed to be used on devices which are not fully controlled by the end user but rather by an external entity, the device administrator. Device administrators are given the power to fully control the managed device.

1.2. Managed configuration

For the purposes of this specification the device administrator can control a list of managed web applications. Each entry in this list can have a set JSON configuration, which is accessible by the documents hosted at the origin of the web application.

Note that this does not apply to anonymous contexts, where the observed state is indistinguishable from a non-managed one.

1.3. Data model

We can assume without loss of generality that managed configuration is stored in a two-level key-value store.

Data model is declared as a map where each key is a configured origin and the value is a

<code>record<DOMString, object></code>
with items corresponding to per-origin configuration keys and their values.

1.4. Data integrity verification

There is no managed configuration verification mechanism defined in the specification, which implies that the website should assume that the configuration could be tampered with, stolen or be replayed on a non-managed device.

Alternative security measures should be put in place by the website itself.

] partial interface Navigator {
  [SecureContext, SameObject]
  readonly attribute NavigatorManagedData managed;

2.1. managed attribute

When getting, the managed attribute always returns the same instance of the NavigatorManagedData object.
] interface NavigatorManagedData : EventTarget {
  // Managed Configuration API.
  Promise<record<DOMString, object>> getManagedConfiguration(sequence<DOMString> keys);
  attribute EventHandler onmanagedconfigurationchange;

Methods on this interface typically complete asynchronously, queuing work on the managed data task source.

3.1. getManagedConfiguration() method

Suppose the following configuration was set by the administrator for the current origin.
   "interactable" : "false",
   "deviceType" : "map"

A client, which would like to get a configuration for a particular key would call:

 .then(function(result) {
     // result = { “interactable” : “false” }
     // Process the value of the key.

For apps that are not managed, the promise gets rejected.

 .then(onSuccess, function(error) { 
      console.log(; // Will print "NotAllowedArror");

The getManagedConfiguration(keys) method steps are:

  1. Let promise be a new promise.

  2. Run the following steps in parallel:

    1. Let map be the data model configured by the device administrator.

    2. Let origin be the relevant global object of this's associated Document's origin.

      NOTE: Third-party contexts have access to the same configuration values as if they were the top-level document.

    3. If there is no entry in the map with key equal to origin, reject promise with a NotAllowedError DOMException.

    4. Create an empty IDL record record.

    5. For each key of the keys, if there is a record with key key in map[origin], add an attribute to record with key as the key and map[origin][key] as the value.

    6. Queue a global task on the relevant global object of this using the managed data task source to resolve promise with record.

  3. Return promise.

3.2. onmanagedconfigurationchange attribute

A client can subscribe to the managed configuration updates by subscribiting to the managedconfigurationchange event.
 function() { 
     // Whenever something changes in the configuration, this method is
     // called.

onmanagedconfigurationchange is an event handler IDL attribute for the managedconfigurationchange event type.

When any of the configuration values under the origin-level key changes for an origin origin, run the following steps:

  1. For each instance data of NavigatorManagedData:

    1. Let document be data’s relevant global object's associated Document.

    2. If document is fully active and document’s origin is equal to origin, fire an event named managedconfigurationchange at data with no value associated with it.

4. Security considerations

In accordance with the modern security practices, the configuration data is designed to be isolated by origin and available to secure contexts only, thus preventing other websites from accessing it.

5. Privacy considerations

Using this API, websites will be capable of identifying managed environments among other non-managed ones. However, this is only possible for web applications which are explicitly configured by the device administrator, which is the whole purpose of this API. Administrator consent for this identification is assumed.

The managed configuration is not exposed to users in anonymous contexts and behaves as if the current origin was not managed.


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.


Terms defined by this specification

Terms defined by reference


Normative References

Anne van Kesteren. DOM Standard. Living Standard. URL:
Anne van Kesteren; et al. HTML Standard. Living Standard. URL:
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL:
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL:
Anne van Kesteren. URL Standard. Living Standard. URL:
Boris Zbarsky. Web IDL. 15 December 2016. ED. URL:

IDL Index

] partial interface Navigator {
  [SecureContext, SameObject]
  readonly attribute NavigatorManagedData managed;

] interface NavigatorManagedData : EventTarget {
  // Managed Configuration API.
  Promise<record<DOMString, object>> getManagedConfiguration(sequence<DOMString> keys);
  attribute EventHandler onmanagedconfigurationchange;