idnits 2.17.1
draft-edge-appconfig-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There is 1 instance of lines with control characters in the document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Unrecognized Status in 'Intended Status: Request for Comments ',
assuming Proposed Standard
(Expected one of 'Standards Track', 'Full Standard', 'Draft Standard',
'Proposed Standard', 'Best Current Practice', 'Informational',
'Experimental', 'Informational', 'Historic'.)
-- The document date (March 2021) is 1138 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Network Working Group C. Edge
2 INTERNET-DRAFT
3 Intended Status: Request for Comments 11 March 2021
4 Expires: July 2021
6 AppConfig for Mobile Applications
7 draft-edge-appconfig-00.txt
9 Status of This Memo
11 This document specifies an Internet standards track protocol for the
12 Internet community, and requests discussion and suggestions for
13 improvements. Please refer to the current edition of the "Internet
14 Official Protocol Standards" (STD 1) for the standardization state and
15 status of this protocol. Distribution of this memo is unlimited.
17 *********************************************************************
19 This is a DRAFT edition of this statement of the Application
20 Configuration protocol (AppConfig). Comments are sought on this document
21 for consideration and possibly incorporated in the final edition.
22 Comments are especially sought from those actually developing MDM and
23 MDM solutions, and particular vendors and potential vendors of
24 applications.
26 The period for comments is 90 days ending April 30, 2021, at which time
27 a revised edition will be issued with a new RFC number.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference material
32 or to cite them other than as "work in progress."
34 Internet-Drafts are working documents of the Internet Engineering Task
35 Force (IETF), its areas, and its working groups. Note that other groups
36 may also distribute working documents as Internet-Drafts.
38 The list of current Internet-Drafts can be accessed at
39 https://www.ietf.org/1id-abstracts.html
41 The list of Internet-Draft Shadow Directories can be accessed at
42 https://www.ietf.org/shadow.html
44 This Internet-Draft is submitted in full conformance with the provisions
45 of BCP 78 and BCP 79.
46 *********************************************************************
47 Abstract
49 Many Service Providers offer application configuration options that
50 manage the state of applications on mobile devices. AppConfig is used to
51 distribute settings to applications upon installation or updated
52 arbitrarily via a trusted Mobile Device Management (MDM) service. This
53 document defines the specification by allowing a standardized format for
54 data to stream into applications via XML (RFC 3470) or JSON interfaces
55 (RFC 4627).
57 Table of Contents
59 1. Introduction 3
60 1.1 Conventions Used in This Document 3
61 1.2 Terminology 3 2. Specification of Requirements 3 3.
62 Requirements 4 4. AppConfig Interaction Procedures 4 4.1
63 Overview 4 4.2 Details 4 5. AppConfig Standards 5
64 5.1 App Configuration Container Elements 5 5.2 Existing Key
65 Standards 5 5.2.1 Backend Configuration 5 5.2.2 User
66 Configuration 6 5.2.4 App Configuration Settings 6 5.2.4
67 App Security Restrictions 6 5.2 App Tunnel Container Elements
68 9 5.3 Single Sign On Container Elements 10 6a. Application
69 Feedback Container Elements 11 7. Security Considerations
70 12 Appendix A. Acknowledgements 12 Appendix B. Normative
71 References 12 Appendix C. Informative References 12
72 1. Abstract
74 Many Service Providers offer application configuration options that
75 manage the state of applications on mobile devices. AppConfig is used to
76 distribute settings to applications upon installation or updated
77 arbitrarily via a trusted Mobile Device Management (MDM) service. This
78 document defines the specification by allowing a standardized format for
79 data to stream into applications via XML (RFC 3470) or JSON interfaces
80 (RFC 4627).
82 2. Introduction
84 AppConfig describes a method by which mobile application vendors can
85 deploy applications with a payload of standard Extensible Markup
86 Language (XML) or JavaScript Object Notation (JSON) that configures
87 settings for application. Settings can include any input streamed to the
88 device over the Internet, leveraging frameworks from an existing Mobile
89 Device Management (MDM) solution for authorization to stream settings
90 into apps at deployment or check-in time.
92 This provides an improvement to developing independent proprietary
93 software development kits (SDKs) to enable configuration and management
94 features of apps through a device management solution. The AppConfig
95 standard allows developers to implement a consistent set of attributes
96 to deploy apps through device management platforms alongside their
97 configuration flow for user credentials for authentication as well as
98 with custom settings or controls in the apps. Standardization also
99 provides multi-platform compatibility and allows for data coming in from
100 app stores and custom-deployed apps concurrently.
102 2.1 Conventions Used in This Document
104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
105 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
106 "OPTIONAL" in this document are to be interpreted as described in
107 RFC 2119.
109 The grammatical rules in this document are to be interpreted as
110 described in RFC 4234.
112 2.2 Terminology
114 Mobile Device Management (MDM) describes a management system used to
115 deploy management commands, apps, and profiles to mobile devices.
117 An object is an unordered collection of zero or more name/value pairs,
118 where a name is a string and a value is a boolean, date, float,
119 floatArray, integer, integerArray, string, or stringArray defined as
120 follows:
122 * boolean: a key containing a 0 for a false state and a 1 for a true
123 state. * date: a key that represents a date represented in the ISO-8601
124 format (e.g. 2019-10-25T21:34:30Z). * float: a decimal value of an
125 integer (e.g. 0.1 or 19.0000333). * floatArray: an array of float
126 objects. * integer is a whole number (e.g. 1 or 64999). * integerArray:
127 an array of zero or more values of whole numbers. * string: A string is
128 a sequence of zero or more Unicode characters * stringArray is an
129 ordered sequence of zero or more values of Unicode strings.
131 The terms "object" and "array" are derived from the conventions of
132 JavaScript.
134 3. Specification of Requirements
136 The problems that are to be solved in the AppConfig standard are mainly
137 three:
139 * Standardize how, when, and why setting objects are deployed to mobile
140 devices * Define the address space to be used so settings are
141 interoperable between application vendors * Define authentication and
142 authorization mechanisms for mobile and web apps
144 The aim of the AppConfig study is to define a plan that solves all
145 these problems as a whole and not each of them separately.
147 The general requirements that we underline for this transition are:
149 - Transparency to MDM and application developers - Flexibility:
150 Simplify the suitability to new communication technology and to
151 topology changes due to new services provided or to different
152 users needs.
154 This specification is designed for use with HTTP or HTTP
155 over TLS. The use of AppConfig over any protocol other than
156 HTTP or HTTP over TLS is out of scope.
158 3a. Requirements
159 There are a number of requirements to using AppConfig.
160 Some are optional, based on the adherence of a particular vendor or
161 implementer to the standard, and their security posture.
163 The device an application is being installed on MUST be enrolled
164 (joined) to an existing MDM.
166 The application (binary) configured by AppConfig MUST be installed by an
167 MDM in order to prevent potentially malicious activity.
169 The MDM server MUST support AppConfig and provide feedback.
171 The MDM server SHOULD support dynamic updating of an application
172 installed using AppConfig.
174 An implementation may set limits on the size of texts that it accepts.
175 An implementation may set limits on the maximum depth of nesting.
176 An implementation may set limits on the range of numbers.
177 An implementation may set limits on the length and character contents
178 of strings.
180 4. AppConfig Interaction Procedures AppConfig leverages existing Mobile
181 Device Management (MDM) technology to run commands on mobile computing
182 devices. Those commands install an app, alongside a profile that
183 configures settings for the app. Those settings are then interpreted by
184 an agent on the device that process the app installation as well as the
185 application of the settings file. Responses are then sent using the
186 AppConfig Application Feedback protocol. The settings and responses are
187 standardized in the AppConfig protocol. The MDM then uses the XML to
188 define and build the User Interface on the admin console. The
189 administrator then uses that console to edit the desired settings and
190 once complete uses the MDM to push the settings to devices per the needs
191 of the platform accepting the management command.
193 4.1 Overview The AppConfig standard communications leverage an existing
194 Mobile Device Management (MDM) framework to send settings into apps.
195 Developers create an XML document per the Managed App Configuration spec
196 for a given app. The XML document is loaded into the MDM and the MDM
197 provides the translation to the platform-specific needs to leverage
198 endpoints available per-platform. Key-value pairs and other elements are
199 then sent over existing frameworks per the documentation of each
200 platform adopting the specification.
202 4.2 Details The flow of information can be seen in Figure 4-2. Here, the
203 following steps are taken:
205 * A: The MDM sends a push notification indicating that a command is
206 waiting to be performed. * B: The client responds to the push
207 notification, checking in and downloading the app to be installed. * C:
208 The MDM sends the bundleID or the URL to a self-published app according
209 to the type of app. * D: The client device downloads the app from the
210 online store or the URL provided. * E: Once the app is installed, the
211 managed app configuration profile is installed.
213 +--------+ +---------------+
214 | | | Push Service |
215 | |<-(A) PUSH app install app. ---| |
216 | | +---------------+
217 | | +---------------+
218 | |--(B) Check in/download app -->| |
219 | Client | | MDM |
220 | |<-(C)---App or app store URL---| |
221 | | +---------------+
222 | | +---------------+
223 | |--(D)----- Download app ------>| |
224 | | | Web Service |
225 | |<-(E)---Profile/app settings---| |
226 +--------+ +---------------+
228 Figure 4-2: AppConfig MDM Interaction Subsequent updates are then
229 handled by repeating steps A, B, and E. Each step in the process is
230 encrypted, but the data at rest on devices may or may not be encrypted.
232 5. AppConfig Standards The AppConfig Standards define the information
233 being send to devices. These involve profiles that contain a number of
234 elements, defined in the following sections. These are comprised of a
235 profile that is interpreted by a process running on the device, per the
236 specifications of each vendor.
238 5.1 App Configuration Container Elements Apps have a number of settings
239 that can be configured, including email addresses, user names, ports,
240 paths, etc. Vendors and administrators also need to limit certain
241 features. These are often configured at the initial installation of the
242 app or ad hoc following that installation. Application Programming
243 Interfaces (APIs) establish a standard for vendors to develop
244 applications to control those objects. The AppConfig protocol allows
245 these objects to be configured by an MDM in a standardized fashion.
246 Applications then interpret the elements of each object that are
247 provided in the form of key-value pairs.
249 The managedApplicationConfiguration is the root element and contains
250 applications to be managed in the form of a bundleID. The bundleId is a
251 string element that specifies the bundle ID of the app that the XML
252 document is associated with. These are portrayed in the XML as follows:
254 com.myCompanyName.mAppName
256 These contain a number of key-value pairs that contain a dictionary of
257 settings (dict for short), a version key, and a presentation key. The
258 Version key is an integer that is 1-5 digits long. For example:
260 2
262 The dictionary contains a number of keyName attributes. This is the name
263 of the key in the key-value pair that the MDM service sends to the app.
264 The app uses this name to look up the configuration setting in the
265 managed app configuration dictionary (e.g. in iOS this is called
266 NSDictionary).
268 The name of the keys must:
270 * Contain only alphanumeric characters, spaces,_(underscore), and -
271 (dash). * Be unique within the dict element (e.g.
272 keyName="allowAdvancedOptions").
274 Keys also have a default value and a constraint. These, respectively,
275 allow a developer to:
277 * Send data into the app container as the value in a key-value pair if
278 the MDM administrator makes no change to the user interface control. *
279 Define the allowable settings for the app. * Display data in the user
280 interface control for the configuration setting.
282 Constraint is the allowable settings in a given field,
283 using the following options:
285 * nullable: Set to true to allow the value in the key-value pair to be
286 null. The default value is false. * min: The lower bound for the value.
287 If the min attribute is not specified, the value has no lower bound. *
288 max: The upper bound for the value. If the max attribute is not
289 specified, the value has no upper bound. * pattern: A regular expression
290 to use to validate a string value of a key.
292 Furter allowable elements that SHOULD be used include the following:
294 * Key: Unique identifier for the key within the app that is being
295 defined. This is then handled as a parameter passed into apps. The key
296 is a maximum 100 characters. * Data: Optional machine-readable value
297 provided by the MDM to allow managing the setting defined in the key.
298 For example, an MDM admin could send a domain name into an app so a user
299 does not need to provide the domain name. Maximum 1000 characters. *
300 Description: Optional description of what the key does, which can be
301 displayed in a management platform, feed, or app. * Version: The version
302 number should be an integer that increases sequentially so the
303 management platform has a trigger to send a new payload to client
304 devices.
306 5.2 Existing Key Standards Keys are camel-cased where each word in a key
307 is separated by an underscore. Keys are used to perform one of four
308 actions:
310 * Backend Configuration: Configures the app to connect to a multi-tenant
311 environment. * User Configuration: Configures the user credentials or
312 sub-tenant * App Configuration Settings: Configures the default or
313 additional settings. Sent as an array of objects. * App Security
314 Restrictions: Configures various features of an app. Examples provided,
315 but extensible.
317 5.2.1 Backend Configuration Performs the connection to a web service for
318 an app. Keys include:
320 * Server_URL: A string containing the URL to access a given web service.
321 * Port: The port to connect to the URL of the web service. * Use_SSL:
322 Boolean that enables an SSL-based connection to the web service. *
323 Tenant_ID: A string that enables a tenant ID for a web service.
325 5.2.2 User Configuration Configures settings for a user of an app on a
326 device. Keys include:
328 * Username: A string that represents the unique name used for a tenant
329 to access a web service over the URL provided. * Email: A string that
330 represents an email address when used in addition or to replace a
331 username. * Domain: A domain name that houses a username and/or email
332 address within a tenant, if required.
334 Note: The underscore separated words are due to the prevalence of
335 acronyms in the strings used.
337 5.2.3 App Configuration MDM Service Settings
339 Where appropriate, developers SHOULD use the MDM service device
340 variables as the default value for key-value pairs where appropriate.
341 These include the following identifiers:
343 * iccid: Integrated Circuit Card Identifier (e.g. 89014104254287052057 *
344 imei: International Mobile Equipment Identity (e.g. 01 342300 291808 3)
345 * imsi: International Mobile Subscriber Identity (e.g. 310150123456789)
346 * meid: Mobile Equipment Identifier (e.g. A0123456789012) * model: The
347 model of the device (e.g. iPhone 10) * phone_Number: The phone number
348 associated with the device * serial_Number: The vendor-supplied serial
349 number of the device * udid: The Unique Device Identifier (e.g.
350 c752e7052fe5e5ca8166e408c4b48573b5b5bd82) * wifi_Mac_Address: Wi-Fi MAC
351 Address (e.g. 30:f7:c5:87:e8:78)
353 5.2.4 Global App Configuration Settings Organizations CAN implement
354 granular app configurations. The client will interpret these as how the
355 app is displayed on the device:
357 * Application_Name: The name of the application as displayed on the
358 device. * Application_Icon: The icon file to be used in the form of a
359 URI to the icon file itself (the format of which can be different per
360 platform and device used. * Arbitrary application keys: Standard key
361 value pairs that control various settings of a given app, defined
362 previously in this document.
364 5.2.5 App Security Restrictions Organizations CAN implement granular
365 security and data loss protection in applications deployed to users.
366 This prevents sensitive data from leaving the control of the company and
367 prevents applications from being used in unintended ways. These security
368 features can be managed in an object-oriented fashion, based on the
369 login built into the MDM. Applications currently have some capabilities
370 to restrict various features through the use of the existing
371 appconfig.org spec or through an SDK; however, this document codifies
372 the use and provides an extensible framework in the form of a namespace
373 schema to be applied to additional capabilities.
375 As with App Configuration Container Elements, some keys are built in, in
376 order to provide compatibility with earlier features and options. These
377 include the following keys and corresponding capabilities:
379 * App_Security_Passcode: Used to set a pincode, fingerprint and/or
380 facial recognition key in an application. *
381 App_Security_Managed_Open_In: Globally restricts all data deployed into
382 a device via an MDM provider from being moved between other objects
383 (e.g. apps, email accounts, etc). * App_Security_Prevent_App_Backup:
384 Interpreted by the mobile device platform to prevent backups to cloud
385 services. * App_Security_Disable_Screen_Capture: Disables the ability
386 for the device to perform a screen capture. *
387 App_Security_Enforce_App_Encryption: Force device passcode security
388 control in MDM; enforces the native data protection encryption. *
389 App_Security_Remotely_Wipe_App: Enables the ability to remotely wipe the
390 app from a device. * App_Security_Disable_Copy_Paste: Disable the
391 ability to copy and paste from within the app to another app.
393 Standard configuration keys for enterprise apps are included in this
394 section of the document; however, each developer can name each key as
395 per their logic, provided the keys do not conflict in namespace with
396 keys provided in the specification. Managed Configuration specification
397 files are then made publicly available to download and consume and when
398 an application is added. The location of the specification file is
399 provided to allow for a consistent display in the MDM and the app.
401 5.2.6 App User Variables A number of uses for app configuration involve
402 the expansion of user-oriented variables. Those are supported based on
403 the users found in the database of the MDM, and/or through a directory
404 service. The built-in options for applications to leverage include the
405 following: * cn: Common Name (CN) attribute extracted from the
406 distinguished name. * displayName: The name displayed in the directory
407 service or interface. * Dn: Distinguished name when used with a common
408 LDAP interface. * emailAddressDomain: The domain portion of the email
409 address. * emailAddressLocalPart: The local portion of the email
410 address. * emailAddress: The full email address for a user. * firstName:
411 The first name of a user. * lastName: The late name or names of a user.
412 * Locale: The language preference for a user. * ou: The Organizational
413 Unit (OU) attribute extracted from the distinguished name. *
414 sAMAccountName: The Microsoft sAMAccountName attribute, for use when
415 Active Directory is the source. * username: The Login ID in the form of
416 an email address. * upn: The Microsoft userPrincipalName attribute (for
417 use when using Active Directory as the source).
419 Federated Identity Management solutions and specs vary from this and
420 integration through those standards are defined later in this document.
422 5.3 Localization Localized strings in the XML document define
423 descriptive text for containers, as it is displayed for additional
424 languages, to render in the administrative console of an MDM product.
425 Localized strings are represented in language elements that contain a
426 string for each language-region code supported. For example:
428 The following elements contain language elements:
430 * Field: The field element defines the admin console UI control for a
431 configuration setting * Description: Elements that render descriptive
432 text about the UI control. * name elements: Specify the name of a group
433 of elements provided as fields (or the field to provide the setting
434 for). * language: Defines the language in the form of a code or where
435 needed language-region code. * type: * selected: Boolean operator that
436 enables the dictionary. * value: The value as output based on the
437 language selected. * defaultLocale: The default language value to be
438 used. * fieldGroup: Defines multiple key elements in a grouping. *
439 option: Defines a list of elements, each SHOULD specify localized option
440 names for an option in environments using select or multiselect UI
441 controls.
443 For example, to define en-US and es-ES, use the following key structure
444 represents keyNames startTime that is Start Time in en-US but then
445 rendered as the Hora de Inicio translation in Spanish and then with
446 descriptive text for each as used in a description field but useable as
447 more:
449
452 The time of day to collect data
453 La hora del dia para recoger los
454 datos
456 This XML files creates a standard scheme to document the accepted
457 configs and values that your app supports. Many MDM vendors support
458 automatically parsing these files in the MDM admin console.
460 5.5 Considerations The application can be a public app in an application
461 store or may be an internally developed app that has been properly
462 signed.
464 According to the vendor implementation, data can be extracted from
465 devices. Therefore, do not use AppConfig Container Elements to store
466 private data such as certificates or passwords. Instead refer to Single
467 Sign-On Container Elements later in this section.
469 Operating system vendors typically SHOULD restrict a device to being
470 enrolled in a single MDM at a time and therefore only one MDM can write
471 to a given AppConfig domain at a time.
473 The MDM system MUST detect and take remediation action on a device that
474 has been compromised (e.g. due to vulnerability or being jailbroken) and
475 that may then expose the managed configurations.
477 Each MDM has the option to setup AppConfig and corresponding services
478 differently. Contact the MDM vendor for documentation specific to their
479 system if needed.
481 Sensitive information such as passwords or certificates should not be
482 sent to the device using this approach.
484 5.2 App Tunnel Container Elements
486 Some applications CAN require access to a given web service that sits
487 behind a firewall. In those cases, the application MAY require a secure
488 application tunnel to connect between an application on a device and the
489 network hosting a server. This might be to access a Federated Identity
490 Provider (IDP) using SAML or OAuth, or for an application to
491 authenticate into a private on premises service.
493 Application tunneling works by connecting an application o a VPN using
494 built-in per-app VPN functionality. The Per-App VPN might be hosted by
495 the MDM or leverage existing infrastructure. The Per-App VPN
496 functionality is deployed using a profile and the device then connects
497 to the service; the application vendor developing the app then has no
498 requirement to develop a specific option in the app.
500 The App Tunnel settings are global on the device. Keys made available to
501 enable this functionality SHOULD include the following:
503 * UserDefinedName: The name displayed in the VPN settings on the device.
504 * VPNType: Defines the settings available for the payload, including
505 L2TP, PPTP, IPSec, IKEv2, AlwaysOn, and VPN. * VPNSubType: Defines the
506 vendor bundle identifier of the VPN plugin used (e.g.
507 com.cisco.anyconnect.applevpn.plugin). * ProviderBundleIdentifier:
508 app-proxy or packet-tunnel to define the option in the vendor *
509 OnDemandEnabled: Boolean that enables the VPN connection when the app is
510 opened. * OnDemandRules: Array defining the options for the on-demand
511 connection, with options definable per device manufacturer and per
512 VPNType.
514 The user of a given app then substantiates the connection to the VPN
515 automatically when the App is opened.
517 5.3 Single Sign-On Container Elements
519 Application developers SHOULD provide a mechanism for users to log into
520 applications using credentials derived from a Federated Identity
521 Provider (IdP). This means supporting a SAML or OAuth that SHOULD allow
522 for multiple authentication flows. The interpretation of required
523 attributes, by application, can then be deployed using an existing
524 technology such as FIDO AppID, Webauthn to embed a screen at initial
525 launch, or a standard flow using a supported app.
527 The applications backend service must support identity federation to an
528 organization identity provider (IDP) via a standard such as SAML, OAuth
529 or other protocols.
531 +--------+ +---------------+
532 | |--(A)- Authorization Request ->| Resource |
533 | | | Owner |
534 | |<-(B)-- Authorization Grant ---| |
535 | | +---------------+
536 | | +---------------+
537 | |--(C)-- Authorization Grant -->| Authorization |
538 | Client | | Server |
539 | |<-(D)----- Access Token -------| |
540 | | +---------------+
541 | | +---------------+
542 | |--(E)----- Access Token ------>| Resource |
543 | | | Server |
544 | |<-(F)--- Protected Resource ---| |
545 +--------+ +---------------+
547 Figure 1: Abstract Protocol Flow
549 Using built-in frameworks mean that when the app is launched, the user
550 will see the identity provider login screen and once the user is
551 authenticated, any future apps that leverage the same identity provider
552 will be able to detect the existing authenticated session and will not
553 need to prompt the user to login again. This standard does not include
554 any specifics for performing these actions other than to indicate that
555 data at rest on devices is often in an unencrypted state and so
556 credentials and/or tokens should not live in the application container
557 or a globally accessible unencrypted location on the device filesystem.
559 6. Application Feedback
561 Mobile Device Management (MDM) providers SHOULD provide an
562 application_feedback REST endpoint to receive a response from the
563 application should the application have information to send to the MDM.
564 The API endpoint available listens for a PUT that contains a keyed app
565 state. That app state contains the status of the apps installed on
566 managed devices and leverages existing encryption for a MDM the device
567 is joined to. As an example a MDM can listen for a custom key that
568 indicates the setup of a given app is complete.
570 6a. Application Feedback Container Elements
572 Components of a keyed app state are represented in the container
573 elements of the application feedback payload. This information is sent
574 back to the MDM by the application using the ManagedApplicationFeedback
575 command over a standard REST interface. These elements are comprised of
576 the following:
578 * Type: The type of feedback in the message. * Key: Unique identifier
579 for the app state. Maximum 100 characters. * Message: Optional message
580 describing the app state. Maximum 1000 characters. Note: Typically
581 messages should be significantly shorter than this. * Data: Optional
582 machine-readable value intended for MDMs to allow IT admins to set up
583 alerts or filters based on the value. For example, an IT admin could set
584 up an alert if the data field battery_percentage < 10. Maximum 1000
585 characters. * Severity: The severity of the app state. Allowable values
586 are SEVERITY_ERROR and SEVERITY_INFO(default). Only set severity to
587 SEVERITY_ERROR for genuine error conditions that an organization needs
588 to take action to fix. * Timestamp: When a keyed app state is set, it's
589 automatically sent with a timestamp in milliseconds since epoch. *
590 DeleteFeedback: Removes the feedback so the feedback is not sent again.
592 To send a ManagedApplicationFeedback command, the server sends a
593 dictionary containing the following keys:
595 * RequestType (String): Contains ManagedApplicationFeedback. *
596 Identifiers (Array): An array of managed bundle identifiers, as strings.
597 * DeleteFeedback (Boolean): Removes the dictionary containing the
598 feedback once read by the MDM.
600 7. Security Considerations As stated in RFC 2617, the greatest sources
601 of risks are usually found not in the core protocol itself but in
602 policies and procedures surrounding its use. Implementers are strongly
603 encouraged to assess how this protocol addresses their security
604 requirements.
606 8. IANA Considerations
608 The values of the Foobar parameter are assigned by the Barfoo
609 registry on behalf of the Rabfoo Forum. Therefore, this document
610 has no IANA actions.
612 Appendix A. Acknowledgements This document is based, in part, on the
613 work done by the Appconfig.org community.
615 This specification is directly based on the AppConfig.org community
616 specification, which in turn was modeled after existing proprietary
617 protocols from Apple and Google, and best practices that have been
618 independently implemented by various companies.
620 The community specification was edited by Pepjin Bruienne, Kyle Hammond,
622 The editor would like to thank the following individuals for their
623 invaluable contribution to the publication of this edition of the
624 protocol: XXX
625 Appendix B. Normative References The normative references used in this
626 document include the following:
628 RFC 2119: https://tools.ietf.org/html/rfc2119 RFC 8174:
629 https://tools.ietf.org/html/rfc8174 HTTP:
630 http://www.rfc-editor.org/info/rfc2616 HTTP over TLS:
631 https://www.rfc-editor.org/info/rfc2818 Oauth 2:
632 https://www.rfc-editor.org/info/rfc6749 XML:
633 http://www.rfc-editor.org/info/rfc3470 JSON:
634 http://www.rfc-editor.org/info/rfc4627 URI:
635 https://tools.ietf.org/html/rfc3986 L2TP:
636 https://tools.ietf.org/html/rfc3931 PPTP:
637 https://tools.ietf.org/html/rfc2637 IPSec:
638 https://tools.ietf.org/html/rfc6071 IKE:
639 https://tools.ietf.org/html/rfc5996 ISO-8601:
640 https://www.iso.org/iso-8601-date-and-time-format.html RFC 4234:
641 https://tools.ietf.org/html/rfc4234 RFC 5198:
642 https://tools.ietf.org/html/rfc5198 RFC 2617:
643 https://tools.ietf.org/html/rfc2617
644 Appendix C. Informative References The informative references used in
645 this document include the following:
647 https://developer.android.com/work/app-feedback/overview
648 https://www.appconfig.org/ios/
649 https://storage.googleapis.com/appconfig-media/appconfig-content/uploads
650 /2017/01/ManagedAppConfig.pdf
651 https://developer.apple.com/business/documentation/MDM-Protocol-
652 Reference.pdf
653 https://developer.apple.com/library/ios/samplecode/sc2279/Introduction/
654 Intro. html
656 Enterprise Distribution
657 https://developers.google.com/android/management/introduction
658 https://docs.aws.amazon.com/iot-device-management/index.html
659 Authors' Address
661 Charles Edge
662 Jamf
663 100 S Washington Ave 1100
664 Minneapolis, MN 55418 US
665 Phone: +1 612 581 6602
666 Email: krypted@jamf.com
668 Bob Whiteman
669 Apple
670 One Infinite Loop Cupertino, CA 95014 US Phone: +1
671 408 606 5775
672 EMail: bwhiteman@apple.com
674 Paul Cerat
675 Microsoft
676 One Microsoft Way
677 Redmond, WA 98052 US Phone: +1
678 425 882 8080
679 EMail: andrew.cerat@microsoft.com
681 Anuj Goyal
682 Google
683 1600 Amphitheatre Parkway
684 Mountain View, California
685 Email: goanuj@google.com
687 Sam Weiss
688 Jamf
689 100 S Washington Ave #1100
690 Minneapolis, MN 55418 US
691 EMail: sam.weiss@jamf.com
693 James Felton
694 Jamf
695 100 S Washington Ave #1100
696 Minneapolis, MN 55418 US
697 EMail: james.felton@jamf.com
699 Kalyan Vishnubhotla
700 MobileIron
701 490 E Middlefield Rd
702 Mountain View, CA
703 94043 US
704 EMail: vkalyan@mobileiron.com
706 Copyright Notice
708 Copyright (c) 2021 IETF Trust and the persons identified as the
709 document authors. All rights reserved.
711 This document is subject to BCP 78 and the IETF Trust's Legal
712 Provisions Relating to IETF Documents
713 (https://trustee.ietf.org/license-info) in effect on the date of
714 publication of this document. Please review these documents
715 carefully, as they describe your rights and restrictions with respect
716 to this document. Code Components extracted from this document must
717 include Simplified BSD License text as described in Section 4.e of
718 the Trust Legal Provisions and are provided without warranty as
719 described in the Simplified BSD License.
721 RFC XXXX AppConfig for Mobile Applications March 2021