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