Internet DRAFT - draft-edge-appconfig
draft-edge-appconfig
Network Working Group C. Edge
INTERNET-DRAFT
Category: Standards Track
Expires: September 2023
Status: Publication Requested
26 September 2022
AppConfig for Mobile Applications
draft-edge-appconfig-01.txt
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
*********************************************************************
This is a DRAFT edition of this statement of the Application
Configuration protocol (AppConfig). Comments are sought on this document
for consideration and possibly incorporated in the final edition.
Comments are especially sought from those actually developing MDM and
MDM solutions, and particular vendors and potential vendors of
applications.
The period for comments is 90 days ending April 30, 2021, at which time
a revised edition will be issued with a new RFC number.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at
https://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
https://www.ietf.org/shadow.html
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
*********************************************************************
C. Edge Standards Track [Page 1]
RFC XXXX AppConfig for Mobile Applications March 2021
Abstract
Many Service Providers offer application configuration options that
manage the state of applications on mobile devices. AppConfig is used to
distribute settings to applications upon installation or updated
arbitrarily via a trusted Mobile Device Management (MDM) service. This
document defines the specification by allowing a standardized format for
data to stream into applications via XML (RFC 3470) or JSON interfaces
(RFC 4627).
Table of Contents
1. Introduction 3
1.1 Conventions Used in This Document 3
1.2 Terminology 3 2. Specification of Requirements 3 3.
Requirements 4 4. AppConfig Interaction Procedures 4 4.1
Overview 4 4.2 Details 4 5. AppConfig Standards 5
5.1 App Configuration Container Elements 5 5.2 Existing Key
Standards 5 5.2.1 Backend Configuration 5 5.2.2 User
Configuration 6 5.2.4 App Configuration Settings 6 5.2.4
App Security Restrictions 6 5.2 App Tunnel Container Elements
9 5.3 Single Sign On Container Elements 10 6a. Application
Feedback Container Elements 11 7. Security Considerations
12 Appendix A. Acknowledgements 12 Appendix B. Normative
References 12 Appendix C. Informative References 12
Edge, et al. Standards Track [Page 2]
RFC XXXX AppConfig for Mobile Applications March 2021
1. Abstract
Many Service Providers offer application configuration options that
manage the state of applications on mobile devices. AppConfig is used to
distribute settings to applications upon installation or updated
arbitrarily via a trusted Mobile Device Management (MDM) service. This
document defines the specification by allowing a standardized format for
data to stream into applications via XML (RFC 3470) or JSON interfaces
(RFC 4627).
2. Introduction
AppConfig describes a method by which mobile application vendors can
deploy applications with a payload of standard Extensible Markup
Language (XML) or JavaScript Object Notation (JSON) that configures
settings for application. Settings can include any input streamed to the
device over the Internet, leveraging frameworks from an existing Mobile
Device Management (MDM) solution for authorization to stream settings
into apps at deployment or check-in time.
This provides an improvement to developing independent proprietary
software development kits (SDKs) to enable configuration and management
features of apps through a device management solution. The AppConfig
standard allows developers to implement a consistent set of attributes
to deploy apps through device management platforms alongside their
configuration flow for user credentials for authentication as well as
with custom settings or controls in the apps. Standardization also
provides multi-platform compatibility and allows for data coming in from
app stores and custom-deployed apps concurrently.
2.1 Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
The grammatical rules in this document are to be interpreted as
described in RFC 4234.
Edge, et al. Standards Track [Page 3]
RFC XXXX AppConfig for Mobile Applications March 2021
2.2 Terminology
Mobile Device Management (MDM) describes a management system used to
deploy management commands, apps, and profiles to mobile devices.
An object is an unordered collection of zero or more name/value pairs,
where a name is a string and a value is a boolean, date, float,
floatArray, integer, integerArray, string, or stringArray defined as
follows:
* boolean: a key containing a 0 for a false state and a 1 for a true
state. * date: a key that represents a date represented in the ISO-8601
format (e.g. 2019-10-25T21:34:30Z). * float: a decimal value of an
integer (e.g. 0.1 or 19.0000333). * floatArray: an array of float
objects. * integer is a whole number (e.g. 1 or 64999). * integerArray:
an array of zero or more values of whole numbers. * string: A string is
a sequence of zero or more Unicode characters * stringArray is an
ordered sequence of zero or more values of Unicode strings.
The terms "object" and "array" are derived from the conventions of
JavaScript.
Edge, et al. Standards Track [Page 4]
RFC XXXX AppConfig for Mobile Applications March 2021
3. Specification of Requirements
The problems that are to be solved in the AppConfig standard are mainly
three:
* Standardize how, when, and why setting objects are deployed to mobile
devices * Define the address space to be used so settings are
interoperable between application vendors * Define authentication and
authorization mechanisms for mobile and web apps
The aim of the AppConfig study is to define a plan that solves all
these problems as a whole and not each of them separately.
The general requirements that we underline for this transition are:
- Transparency to MDM and application developers - Flexibility:
Simplify the suitability to new communication technology and to
topology changes due to new services provided or to different
users needs.
This specification is designed for use with HTTP or HTTP
over TLS. The use of AppConfig over any protocol other than
HTTP or HTTP over TLS is out of scope.
Edge, et al. Standards Track [Page 5]
RFC XXXX AppConfig for Mobile Applications March 2021
3a. Requirements
There are a number of requirements to using AppConfig.
Some are optional, based on the adherence of a particular vendor or
implementer to the standard, and their security posture.
The device an application is being installed on MUST be enrolled
(joined) to an existing MDM.
The application (binary) configured by AppConfig MUST be installed by an
MDM in order to prevent potentially malicious activity.
The MDM server MUST support AppConfig and provide feedback.
The MDM server SHOULD support dynamic updating of an application
installed using AppConfig.
An implementation may set limits on the size of texts that it accepts.
An implementation may set limits on the maximum depth of nesting.
An implementation may set limits on the range of numbers.
An implementation may set limits on the length and character contents
of strings.
Edge, et al. Standards Track [Page 6]
RFC XXXX AppConfig for Mobile Applications March 2021
4. AppConfig Interaction Procedures AppConfig leverages existing Mobile
Device Management (MDM) technology to run commands on mobile computing
devices. Those commands install an app, alongside a profile that
configures settings for the app. Those settings are then interpreted by
an agent on the device that process the app installation as well as the
application of the settings file. Responses are then sent using the
AppConfig Application Feedback protocol. The settings and responses are
standardized in the AppConfig protocol. The MDM then uses the XML to
define and build the User Interface on the admin console. The
administrator then uses that console to edit the desired settings and
once complete uses the MDM to push the settings to devices per the needs
of the platform accepting the management command.
4.1 Overview The AppConfig standard communications leverage an existing
Mobile Device Management (MDM) framework to send settings into apps.
Developers create an XML document per the Managed App Configuration spec
for a given app. The XML document is loaded into the MDM and the MDM
provides the translation to the platform-specific needs to leverage
endpoints available per-platform. Key-value pairs and other elements are
then sent over existing frameworks per the documentation of each
platform adopting the specification.
4.2 Details The flow of information can be seen in Figure 4-2. Here, the
following steps are taken:
Edge, et al. Standards Track [Page 7]
RFC XXXX AppConfig for Mobile Applications March 2021
* A: The MDM sends a push notification indicating that a command is
waiting to be performed. * B: The client responds to the push
notification, checking in and downloading the app to be installed. * C:
The MDM sends the bundleID or the URL to a self-published app according
to the type of app. * D: The client device downloads the app from the
online store or the URL provided. * E: Once the app is installed, the
managed app configuration profile is installed.
+--------+ +---------------+
| | | Push Service |
| |<-(A) PUSH app install app. ---| |
| | +---------------+
| | +---------------+
| |--(B) Check in/download app -->| |
| Client | | MDM |
| |<-(C)---App or app store URL---| |
| | +---------------+
| | +---------------+
| |--(D)----- Download app ------>| |
| | | Web Service |
| |<-(E)---Profile/app settings---| |
+--------+ +---------------+
Figure 4-2: AppConfig MDM Interaction Subsequent updates are then
handled by repeating steps A, B, and E. Each step in the process is
encrypted, but the data at rest on devices may or may not be encrypted.
Edge, et al. Standards Track [Page 8]
RFC XXXX AppConfig for Mobile Applications March 2021
5. AppConfig Standards The AppConfig Standards define the information
being send to devices. These involve profiles that contain a number of
elements, defined in the following sections. These are comprised of a
profile that is interpreted by a process running on the device, per the
specifications of each vendor.
5.1 App Configuration Container Elements Apps have a number of settings
that can be configured, including email addresses, user names, ports,
paths, etc. Vendors and administrators also need to limit certain
features. These are often configured at the initial installation of the
app or ad hoc following that installation. Application Programming
Interfaces (APIs) establish a standard for vendors to develop
applications to control those objects. The AppConfig protocol allows
these objects to be configured by an MDM in a standardized fashion.
Applications then interpret the elements of each object that are
provided in the form of key-value pairs.
The managedApplicationConfiguration is the root element and contains
applications to be managed in the form of a bundleID. The bundleId is a
string element that specifies the bundle ID of the app that the XML
document is associated with. These are portrayed in the XML as follows:
<bundleId>com.myCompanyName.mAppName</bundleId>
These contain a number of key-value pairs that contain a dictionary of
settings (dict for short), a version key, and a presentation key. The
Version key is an integer that is 1-5 digits long. For example:
<version>2</version>
The dictionary contains a number of keyName attributes. This is the name
of the key in the key-value pair that the MDM service sends to the app.
The app uses this name to look up the configuration setting in the
managed app configuration dictionary (e.g. in iOS this is called
NSDictionary).
Edge, et al. Standards Track [Page 9]
RFC XXXX AppConfig for Mobile Applications March 2021
The name of the keys must:
* Contain only alphanumeric characters, spaces,_(underscore), and -
(dash). * Be unique within the dict element (e.g.
keyName="allowAdvancedOptions").
Keys also have a default value and a constraint. These, respectively,
allow a developer to:
* Send data into the app container as the value in a key-value pair if
the MDM administrator makes no change to the user interface control. *
Define the allowable settings for the app. * Display data in the user
interface control for the configuration setting.
Constraint is the allowable settings in a given field,
using the following options:
* nullable: Set to true to allow the value in the key-value pair to be
null. The default value is false. * min: The lower bound for the value.
If the min attribute is not specified, the value has no lower bound. *
max: The upper bound for the value. If the max attribute is not
specified, the value has no upper bound. * pattern: A regular expression
to use to validate a string value of a key.
Edge, et al. Standards Track [Page 10]
RFC XXXX AppConfig for Mobile Applications March 2021
Furter allowable elements that SHOULD be used include the following:
* Key: Unique identifier for the key within the app that is being
defined. This is then handled as a parameter passed into apps. The key
is a maximum 100 characters. * Data: Optional machine-readable value
provided by the MDM to allow managing the setting defined in the key.
For example, an MDM admin could send a domain name into an app so a user
does not need to provide the domain name. Maximum 1000 characters. *
Description: Optional description of what the key does, which can be
displayed in a management platform, feed, or app. * Version: The version
number should be an integer that increases sequentially so the
management platform has a trigger to send a new payload to client
devices.
5.2 Existing Key Standards Keys are camel-cased where each word in a key
is separated by an underscore. Keys are used to perform one of four
actions:
* Backend Configuration: Configures the app to connect to a multi-tenant
environment. * User Configuration: Configures the user credentials or
sub-tenant * App Configuration Settings: Configures the default or
additional settings. Sent as an array of objects. * App Security
Restrictions: Configures various features of an app. Examples provided,
but extensible.
5.2.1 Backend Configuration Performs the connection to a web service for
an app. Keys include:
* Server_URL: A string containing the URL to access a given web service.
* Port: The port to connect to the URL of the web service. * Use_SSL:
Boolean that enables an SSL-based connection to the web service. *
Tenant_ID: A string that enables a tenant ID for a web service.
Edge, et al. Standards Track [Page 11]
RFC XXXX AppConfig for Mobile Applications March 2021
5.2.2 User Configuration Configures settings for a user of an app on a
device. Keys include:
* Username: A string that represents the unique name used for a tenant
to access a web service over the URL provided. * Email: A string that
represents an email address when used in addition or to replace a
username. * Domain: A domain name that houses a username and/or email
address within a tenant, if required.
Note: The underscore separated words are due to the prevalence of
acronyms in the strings used.
5.2.3 App Configuration MDM Service Settings
Where appropriate, developers SHOULD use the MDM service device
variables as the default value for key-value pairs where appropriate.
These include the following identifiers:
* iccid: Integrated Circuit Card Identifier (e.g. 89014104254287052057 *
imei: International Mobile Equipment Identity (e.g. 01 342300 291808 3)
* imsi: International Mobile Subscriber Identity (e.g. 310150123456789)
* meid: Mobile Equipment Identifier (e.g. A0123456789012) * model: The
model of the device (e.g. iPhone 10) * phone_Number: The phone number
associated with the device * serial_Number: The vendor-supplied serial
number of the device * udid: The Unique Device Identifier (e.g.
c752e7052fe5e5ca8166e408c4b48573b5b5bd82) * wifi_Mac_Address: Wi-Fi MAC
Address (e.g. 30:f7:c5:87:e8:78)
5.2.4 Global App Configuration Settings Organizations CAN implement
granular app configurations. The client will interpret these as how the
app is displayed on the device:
* Application_Name: The name of the application as displayed on the
device. * Application_Icon: The icon file to be used in the form of a
URI to the icon file itself (the format of which can be different per
platform and device used. * Arbitrary application keys: Standard key
value pairs that control various settings of a given app, defined
previously in this document.
Edge, et al. Standards Track [Page 12]
RFC XXXX AppConfig for Mobile Applications March 2021
5.2.5 App Security Restrictions Organizations CAN implement granular
security and data loss protection in applications deployed to users.
This prevents sensitive data from leaving the control of the company and
prevents applications from being used in unintended ways. These security
features can be managed in an object-oriented fashion, based on the
login built into the MDM. Applications currently have some capabilities
to restrict various features through the use of the existing
appconfig.org spec or through an SDK; however, this document codifies
the use and provides an extensible framework in the form of a namespace
schema to be applied to additional capabilities.
As with App Configuration Container Elements, some keys are built in, in
order to provide compatibility with earlier features and options. These
include the following keys and corresponding capabilities:
* App_Security_Passcode: Used to set a pincode, fingerprint and/or
facial recognition key in an application. *
App_Security_Managed_Open_In: Globally restricts all data deployed into
a device via an MDM provider from being moved between other objects
(e.g. apps, email accounts, etc). * App_Security_Prevent_App_Backup:
Interpreted by the mobile device platform to prevent backups to cloud
services. * App_Security_Disable_Screen_Capture: Disables the ability
for the device to perform a screen capture. *
App_Security_Enforce_App_Encryption: Force device passcode security
control in MDM; enforces the native data protection encryption. *
App_Security_Remotely_Wipe_App: Enables the ability to remotely wipe the
app from a device. * App_Security_Disable_Copy_Paste: Disable the
ability to copy and paste from within the app to another app.
Standard configuration keys for enterprise apps are included in this
section of the document; however, each developer can name each key as
per their logic, provided the keys do not conflict in namespace with
keys provided in the specification. Managed Configuration specification
files are then made publicly available to download and consume and when
an application is added. The location of the specification file is
provided to allow for a consistent display in the MDM and the app.
Edge, et al. Standards Track [Page 13]
RFC XXXX AppConfig for Mobile Applications March 2021
5.2.6 App User Variables A number of uses for app configuration involve
the expansion of user-oriented variables. Those are supported based on
the users found in the database of the MDM, and/or through a directory
service. The built-in options for applications to leverage include the
following: * cn: Common Name (CN) attribute extracted from the
distinguished name. * displayName: The name displayed in the directory
service or interface. * Dn: Distinguished name when used with a common
LDAP interface. * emailAddressDomain: The domain portion of the email
address. * emailAddressLocalPart: The local portion of the email
address. * emailAddress: The full email address for a user. * firstName:
The first name of a user. * lastName: The late name or names of a user.
* Locale: The language preference for a user. * ou: The Organizational
Unit (OU) attribute extracted from the distinguished name. *
sAMAccountName: The Microsoft sAMAccountName attribute, for use when
Active Directory is the source. * username: The Login ID in the form of
an email address. * upn: The Microsoft userPrincipalName attribute (for
use when using Active Directory as the source).
Federated Identity Management solutions and specs vary from this and
integration through those standards are defined later in this document.
5.3 Localization Localized strings in the XML document define
descriptive text for containers, as it is displayed for additional
languages, to render in the administrative console of an MDM product.
Localized strings are represented in language elements that contain a
string for each language-region code supported. For example:
The following elements contain language elements:
* Field: The field element defines the admin console UI control for a
configuration setting * Description: Elements that render descriptive
text about the UI control. * name elements: Specify the name of a group
of elements provided as fields (or the field to provide the setting
for). * language: Defines the language in the form of a code or where
needed language-region code. * type: * selected: Boolean operator that
enables the dictionary. * value: The value as output based on the
language selected. * defaultLocale: The default language value to be
used. * fieldGroup: Defines multiple key elements in a grouping. *
option: Defines a list of elements, each SHOULD specify localized option
names for an option in environments using select or multiselect UI
controls.
Edge, et al. Standards Track [Page 14]
RFC XXXX AppConfig for Mobile Applications March 2021
For example, to define en-US and es-ES, use the following key structure
represents keyNames startTime that is Start Time in en-US but then
rendered as the Hora de Inicio translation in Spanish and then with
descriptive text for each as used in a description field but useable as
more:
<presentation defaultLocale="en-US"> <field keyName="startTime"
type="input"> <label> <language value="en-US">Start Time</language>
<language value="es-ES">Hora de Inicio</language> </label> <description>
<language value="en-US">The time of day to collect data</language>
<language value="en-US">La hora del dia para recoger los
datos</language> </description> </field> </presentation>
This XML files creates a standard scheme to document the accepted
configs and values that your app supports. Many MDM vendors support
automatically parsing these files in the MDM admin console.
5.5 Considerations The application can be a public app in an application
store or may be an internally developed app that has been properly
signed.
According to the vendor implementation, data can be extracted from
devices. Therefore, do not use AppConfig Container Elements to store
private data such as certificates or passwords. Instead refer to Single
Sign-On Container Elements later in this section.
Operating system vendors typically SHOULD restrict a device to being
enrolled in a single MDM at a time and therefore only one MDM can write
to a given AppConfig domain at a time.
The MDM system MUST detect and take remediation action on a device that
has been compromised (e.g. due to vulnerability or being jailbroken) and
that may then expose the managed configurations.
Edge, et al. Standards Track [Page 15]
RFC XXXX AppConfig for Mobile Applications March 2021
Each MDM has the option to setup AppConfig and corresponding services
differently. Contact the MDM vendor for documentation specific to their
system if needed.
Sensitive information such as passwords or certificates should not be
sent to the device using this approach.
5.2 App Tunnel Container Elements
Some applications CAN require access to a given web service that sits
behind a firewall. In those cases, the application MAY require a secure
application tunnel to connect between an application on a device and the
network hosting a server. This might be to access a Federated Identity
Provider (IDP) using SAML or OAuth, or for an application to
authenticate into a private on premises service.
Application tunneling works by connecting an application o a VPN using
built-in per-app VPN functionality. The Per-App VPN might be hosted by
the MDM or leverage existing infrastructure. The Per-App VPN
functionality is deployed using a profile and the device then connects
to the service; the application vendor developing the app then has no
requirement to develop a specific option in the app.
The App Tunnel settings are global on the device. Keys made available to
enable this functionality SHOULD include the following:
* UserDefinedName: The name displayed in the VPN settings on the device.
* VPNType: Defines the settings available for the payload, including
L2TP, PPTP, IPSec, IKEv2, AlwaysOn, and VPN. * VPNSubType: Defines the
vendor bundle identifier of the VPN plugin used (e.g.
com.cisco.anyconnect.applevpn.plugin). * ProviderBundleIdentifier:
app-proxy or packet-tunnel to define the option in the vendor *
OnDemandEnabled: Boolean that enables the VPN connection when the app is
opened. * OnDemandRules: Array defining the options for the on-demand
connection, with options definable per device manufacturer and per
VPNType.
The user of a given app then substantiates the connection to the VPN
automatically when the App is opened.
Edge, et al. Standards Track [Page 16]
RFC XXXX AppConfig for Mobile Applications March 2021
5.3 Single Sign-On Container Elements
Application developers SHOULD provide a mechanism for users to log into
applications using credentials derived from a Federated Identity
Provider (IdP). This means supporting a SAML or OAuth that SHOULD allow
for multiple authentication flows. The interpretation of required
attributes, by application, can then be deployed using an existing
technology such as FIDO AppID, Webauthn to embed a screen at initial
launch, or a standard flow using a supported app.
The applications backend service must support identity federation to an
organization identity provider (IDP) via a standard such as SAML, OAuth
or other protocols.
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol Flow
Using built-in frameworks mean that when the app is launched, the user
will see the identity provider login screen and once the user is
authenticated, any future apps that leverage the same identity provider
will be able to detect the existing authenticated session and will not
need to prompt the user to login again. This standard does not include
any specifics for performing these actions other than to indicate that
data at rest on devices is often in an unencrypted state and so
credentials and/or tokens should not live in the application container
or a globally accessible unencrypted location on the device filesystem.
Edge, et al. Standards Track [Page 17]
RFC XXXX AppConfig for Mobile Applications March 2021
6. Application Feedback
Mobile Device Management (MDM) providers SHOULD provide an
application_feedback REST endpoint to receive a response from the
application should the application have information to send to the MDM.
The API endpoint available listens for a PUT that contains a keyed app
state. That app state contains the status of the apps installed on
managed devices and leverages existing encryption for a MDM the device
is joined to. As an example a MDM can listen for a custom key that
indicates the setup of a given app is complete.
6a. Application Feedback Container Elements
Components of a keyed app state are represented in the container
elements of the application feedback payload. This information is sent
back to the MDM by the application using the ManagedApplicationFeedback
command over a standard REST interface. These elements are comprised of
the following:
* Type: The type of feedback in the message. * Key: Unique identifier
for the app state. Maximum 100 characters. * Message: Optional message
describing the app state. Maximum 1000 characters. Note: Typically
messages should be significantly shorter than this. * Data: Optional
machine-readable value intended for MDMs to allow IT admins to set up
alerts or filters based on the value. For example, an IT admin could set
up an alert if the data field battery_percentage < 10. Maximum 1000
characters. * Severity: The severity of the app state. Allowable values
are SEVERITY_ERROR and SEVERITY_INFO(default). Only set severity to
SEVERITY_ERROR for genuine error conditions that an organization needs
to take action to fix. * Timestamp: When a keyed app state is set, it's
automatically sent with a timestamp in milliseconds since epoch. *
DeleteFeedback: Removes the feedback so the feedback is not sent again.
To send a ManagedApplicationFeedback command, the server sends a
dictionary containing the following keys:
* RequestType (String): Contains ManagedApplicationFeedback. *
Identifiers (Array): An array of managed bundle identifiers, as strings.
* DeleteFeedback (Boolean): Removes the dictionary containing the
feedback once read by the MDM.
Edge, et al. Standards Track [Page 18]
RFC XXXX AppConfig for Mobile Applications March 2021
7. Security Considerations As stated in RFC 2617, the greatest sources
of risks are usually found not in the core protocol itself but in
policies and procedures surrounding its use. Implementers are strongly
encouraged to assess how this protocol addresses their security
requirements.
8. IANA Considerations
The values of the Foobar parameter are assigned by the Barfoo
registry on behalf of the Rabfoo Forum. Therefore, this document
has no IANA actions.
Edge, et al. Standards Track [Page 19]
RFC XXXX AppConfig for Mobile Applications March 2021
Appendix A. Acknowledgements This document is based, in part, on the
work done by the Appconfig.org community.
This specification is directly based on the AppConfig.org community
specification, which in turn was modeled after existing proprietary
protocols from Apple and Google, and best practices that have been
independently implemented by various companies.
The community specification was edited by Pepjin Bruienne, Kyle Hammond,
The editor would like to thank the following individuals for their
invaluable contribution to the publication of this edition of the
protocol: XXX
Edge, et al. Standards Track [Page 20]
RFC XXXX AppConfig for Mobile Applications March 2021
Appendix B. Normative References The normative references used in this
document include the following:
RFC 2119: https://tools.ietf.org/html/rfc2119 RFC 8174:
https://tools.ietf.org/html/rfc8174 HTTP:
http://www.rfc-editor.org/info/rfc2616 HTTP over TLS:
https://www.rfc-editor.org/info/rfc2818 Oauth 2:
https://www.rfc-editor.org/info/rfc6749 XML:
http://www.rfc-editor.org/info/rfc3470 JSON:
http://www.rfc-editor.org/info/rfc4627 URI:
https://tools.ietf.org/html/rfc3986 L2TP:
https://tools.ietf.org/html/rfc3931 PPTP:
https://tools.ietf.org/html/rfc2637 IPSec:
https://tools.ietf.org/html/rfc6071 IKE:
https://tools.ietf.org/html/rfc5996 ISO-8601:
https://www.iso.org/iso-8601-date-and-time-format.html RFC 4234:
https://tools.ietf.org/html/rfc4234 RFC 5198:
https://tools.ietf.org/html/rfc5198 RFC 2617:
https://tools.ietf.org/html/rfc2617
Edge, et al. Standards Track [Page 21]
RFC XXXX AppConfig for Mobile Applications March 2021
Appendix C. Informative References The informative references used in
this document include the following:
https://developer.android.com/work/app-feedback/overview
https://www.appconfig.org/ios/
https://storage.googleapis.com/appconfig-media/appconfig-content/uploads
/2017/01/ManagedAppConfig.pdf
https://developer.apple.com/business/documentation/MDM-Protocol-
Reference.pdf
https://developer.apple.com/library/ios/samplecode/sc2279/Introduction/
Intro. html
Enterprise Distribution
https://developers.google.com/android/management/introduction
https://docs.aws.amazon.com/iot-device-management/index.html
Edge, et al. Standards Track [Page 22]
RFC XXXX AppConfig for Mobile Applications March 2021
Authors' Address
Charles Edge
Jamf
100 S Washington Ave 1100
Minneapolis, MN 55418 US
Phone: +1 612 581 6602
Email: krypted@jamf.com
Bob Whiteman
Apple
One Infinite Loop Cupertino, CA 95014 US Phone: +1
408 606 5775
EMail: bwhiteman@apple.com
Paul Cerat
Microsoft
One Microsoft Way
Redmond, WA 98052 US Phone: +1
425 882 8080
EMail: andrew.cerat@microsoft.com
Anuj Goyal
Google
1600 Amphitheatre Parkway
Mountain View, California
Email: goanuj@google.com
Sam Weiss
Jamf
100 S Washington Ave #1100
Minneapolis, MN 55418 US
EMail: sam.weiss@jamf.com
James Felton
Jamf
100 S Washington Ave #1100
Minneapolis, MN 55418 US
EMail: james.felton@jamf.com
Kalyan Vishnubhotla
MobileIron
490 E Middlefield Rd
Mountain View, CA
94043 US
EMail: vkalyan@mobileiron.com
Edge, et al. Standards Track [Page 23]
RFC XXXX AppConfig for Mobile Applications March 2021
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Edge, et al. Standards Track [Page 24]
RFC XXXX AppConfig for Mobile Applications March 2021
