RFC 9944: Device Schema Extensions to the System for Cross-Domain Identity Management (SCIM) Model
- M. Shahzad,
- H. Iqbal,
- E. Lear
Abstract
The initial core schema for the System for Cross-domain Identity Management (SCIM) was designed for provisioning users. This memo specifies schema extensions that enable provisioning of devices using various underlying bootstrapping systems such as Wi-Fi Easy Connect, FIDO device onboarding vouchers, Bluetooth Low Energy (BLE) passcodes, and MAC Authenticated Bypass (MAB).¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2026 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://
1. Introduction
The Internet of Things presents a management challenge in many dimensions. One of them is the ability to onboard and manage a large number of devices. There are many models for bootstrapping trust between devices and network deployments. Indeed, it is expected that different manufacturers will make use of different methods.¶
The System for Cross-domain Identity Management (SCIM) [RFC7643] [RFC7644] defines a protocol and a schema for the provisioning of users. However, it can easily be extended to provision device credentials and other attributes into a network. The protocol and core schema were designed to permit just such extensions. Bulk operations are supported. This is good because often devices are procured in bulk.¶
A primary purpose of this specification is to provision the network for onboarding and communications access to and from devices within a local deployment based on the underlying capabilities of those devices.¶
The underlying security mechanisms of some devices range from non-existent such as the Bluetooth Low Energy (BLE) "Just Works" pairing method to a robust FIDO Device Onboard (FDO) mechanism. Information from the SCIM server is dispatched to control functions based on selected schema extensions to enable these communications within a network. The SCIM database is therefore essentially equivalent to a network's Authentication, Authorization, and Accounting (AAA) database and should be carefully managed as such.¶
1.1. Why SCIM for Devices?
There are a number of existing models that might provide the basis for a scheme for provisioning devices onto a network, including two standardized by the IETF: NETCONF [RFC6241] or RESTCONF [RFC8040] with YANG [RFC7950]. SCIM was chosen for the following reasons:¶
This taken together with the fact that end devices are not intended to be directly configured leaves us with SCIM as the best standard option.¶
1.2. Protocol Participants
In the normal SCIM model, it was presumed that large federated deployments would be SCIM clients who provision and remove employees and contractors as they enter and depart those deployments, and federated services such as sales, payment, or conferencing services would be the servers.¶
In the device model, the roles are reversed and may be somewhat more varied. The SCIM server resides within a deployment and is used for receiving information about devices that are expected to be connected to its network. That server will apply appropriate local policies regarding whether/how the device should be connected.¶
The client may be one of a number of entities:¶
In Figure 1, the onboarding application (app) provides the device particulars,
which will vary based on the type of device, as indicated by the
selection of schema extensions. As
part of the response, the SCIM server might provide additional
information, especially in the case of non-IP devices, where an
application
Figure 2 shows how IP-based endpoints can be provisioned. In this case, the onboarding application provisions a device via SCIM. The necessary information is passed to the Authentication, Authorization, and Accounting (AAA) subsystem, such that the device is permitted to connect. Once it is online, since the device is based on IP, it will not need an ALG, but it will use the normal IP infrastructure to communicate with its control application.¶
1.3. Schema Description
[RFC7643] does not prescribe a language to describe a schema but instead uses a narrative description with examples. We follow that approach. In addition, we provide non-normative JSON Schemas [JSONSchema] and OpenAPI [OpenAPI] versions in the appendices for ease of implementation, neither of which existed when SCIM was originally developed. The only difference the authors note between the normative schema representations is that the JSON Schemas and OpenAPI versions do not have a means to express case sensitivity, and thus attributes that are not case sensitive must be manually validated.¶
Several additional schemas specify specific onboarding mechanisms, such as Bluetooth Low Energy (BLE) [BLE54], Wi-Fi Easy Connect [DPP2], and FIDO Device Onboard [FDO11].¶
When JSON is presented in this memo, it is folded in accordance with [RFC8792].¶
1.4. Schema Representation
Attributes defined in the device core schema (see Section 2.2 of [RFC7643]) and extensions comprise characteristics and the SCIM datatypes (defined in Section 2.3 of [RFC7643]). This specification does not define new characteristics and datatypes for the SCIM attributes.¶
1.5. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The reader is also expected to be familiar with the narrative schema language used in [RFC7643].¶
2. ResourceType Device
A new resource type Device is specified. The "ResourceType" schema specifies the metadata about a resource type (see Section 6 of [RFC7643]). It comprises a core device schema and several extension schemas. This schema provides a minimal resource representation, whereas extension schemas extend it depending on the device's capability.¶
2.1. Common Attributes
The device schema contains three common attributes as defined in Section 3.1 of [RFC7643]. No semantic or syntax changes are made here, but the attributes are listed merely for completeness.¶
- id:
-
A required and unique attribute of the core device schema (see Section 3.1 of [RFC7643]).¶
- externalId:
-
An optional attribute (see Section 3.1 of [RFC7643]).¶
- meta:
-
A required and complex attribute (see Section 3.1 of [RFC7643]).¶
3. SCIM Core Device Schema
The core device schema provides the minimal representation of a resource Device. It contains only those attributes that any device may need, and only one attribute is required. It is identified using the schema URI:¶
urn
The following attributes are defined in the core device schema.¶
3.1. Singular Attributes
- displayName:
-
A string that provides a human-readable name for a device. It is intended to be displayed to end users and should be suitable for that purpose. The attribute is not required and is not case sensitive. It may be modified and SHOULD be returned by default. No uniqueness constraints are imposed on this attribute.¶
- active:
-
A mutable boolean that is required. If set to true, it means that this device is intended to be operational. Attempts to control or access a device where this value is set to false may fail. For example, when used in conjunction with Non
-Internet -Connected Physical Components (NIPC) [NIPC], commands (such as connect, disconnect, and subscribe) that control application sends to the controller for devices will be rejected by the controller.¶ - mudUrl:
-
A string that represents the URL to the Manufacturer Usage Description (MUD) file associated with this device. This attribute is optional, mutable, and returned by default. When present, this attribute may be used as described in [RFC8520]. The mudUrl value is case sensitive and not unique.¶
- groups:
-
An optional read-only complex object that indicates group membership. Its form is precisely the same as that defined in Section 4.1.2 of [RFC7643].¶
- Legend:
- Req = Required, T = True, F = False, RO = ReadOnly, RW = ReadWrite, Def = Default¶
Example:¶
4. Groups
Device and EndpointApp groups are created using the SCIM groups as defined in Section 4.2 of [RFC7643]. If set, the "type" subattribute of the "members" attribute MUST be set to Device for devices and EndpointApp for endpoint applications.¶
5. Resource Type EndpointApp
This section defines the EndpointApp resource type. The "ResourceType" schema specifies the metadata about a resource type (see Section 6 of [RFC7643]). The resource EndpointApp represents client applications that can control and/or receive data from the devices.¶
6. SCIM EndpointApp Schema
The EndpointApp schema is used to authorize control or telemetry services for clients. The schema identifies the application and how clients are to authenticate to the various services.¶
The schema for EndpointApp is identified using the schema URI:¶
urn
The following attributes are defined in this schema.¶
6.1. Common Attributes
Like Section 2.1, the EndpointApp schema contains the three common attributes specified in Section 3.1 of [RFC7643].¶
6.2. Singular Attributes
- applicationType:
-
A string that represents the type of application. It will only contain two values: deviceControl or telemetry. deviceControl is the application that sends commands to control the device. telemetry is the application that receives data from the device. The attribute is required and is not case sensitive. The attribute is immutable and should be returned by default. No uniqueness constraints are imposed on this attribute.¶
- applicationName:
-
A string that represents a human-readable name for the application. This attribute is required and mutable. The attribute should be returned by default and there is no uniqueness constraint on the attribute.¶
- clientToken:
-
A string that contains a token that the client will use to authenticate itself. Each token may be a string up to 500 characters in length. It is not mutable. It is read-only, case sensitive, and generated if no certificateInfo object is provisioned. It is returned by default if it exists. The SCIM server should expect that client tokens will be shared by the SCIM client with other components within the client's infrastructure.¶
- groups:
-
An optional read-only complex object that indicates group membership. Its form is precisely the same as that defined in Section 4.1.2 of [RFC7643].¶
6.3. Complex Attributes
6.3.1. certificateInfo
certificateInfo is a complex attribute that contains an X.509 certificate's subject name and root Certificate Authority (CA) information associated with application clients that will connect for purposes of device control or telemetry.¶
- rootCA:
-
A base64-encoded string as described in Section 4 of [RFC4648]. It is a trust anchor certificate applicable for certificates used for client application access. The object is not required. It is singular, case sensitive, and read/write. If not present, a set of trust anchors MUST be configured out of band.¶
- subjectName:
-
A string that contains one of two names:¶
In the latter case, servers validating such certificates SHALL reject connections when the name of the peer as resolved by a DNS reverse lookup does not match the dnsName in the certificate. If multiple dnsNames are present, it is left to server implementations to address any authorization conflicts associated with those names. This attribute is not required and not case sensitive. It is mutable and singular.¶
- Legend:
- Req = Required, T = True, F = False, RO = ReadOnly, RW = ReadWrite, N = No, Def = Default, Imm = Immutable¶
If certificateInfo is provided by the client and is accepted by the server, the server MUST return that multivalued attribute in its response. Otherwise, the server is expected to return a clientToken. If the server returns neither certificateInfo nor a clientToken, then external authentication such as [OAUTHv2] MUST be pre-arranged. If the server accepts a certificate and produces a clientToken, then control and telemetry servers MUST validate both.¶
certificateInfo is preferred in situations where client functions are federated such that different clients may connect for different purposes.¶
Example:¶
7. SCIM Device Extensions
SCIM provides various extension schemas and their attributes, along
with JSON representations and example objects. The core schema is
extended with a new resource type, Device. No schema
7.1. Bluetooth Low Energy (BLE) Extension
This schema extends the device schema to represent the devices supporting BLE. The extension is identified using the following schema URI:¶
urn
The attributes are as follows.¶
7.1.1. Singular Attributes
- device
Mac Address : -
A string value that represents a public MAC address assigned by the manufacturer. It is a unique 48-bit value. It is required, case insensitive, mutable, and returned by default. The ECMA regular expression pattern [ECMA] is the following:¶
- isRandom:
-
A boolean flag. If false, the device is using a public MAC address. If true, the device uses a random address. If an Identifying Resolving Key (IRK) is present, the address represents a resolvable private address. Otherwise, the address is assumed to be a random static address. Non-resolvable private addresses are not supported by this specification. This attribute is not required. It is mutable and is returned by default. The default value is false. See Volume 6, Part B, Section 1.3 of [BLE54] for more information about different address types.¶
- separate
Broadcast Address : -
When present, this string represents an address used for broadcasts
/advertisements . This value MUST NOT be set when an IRK is provided. Its form is the same as device Mac Address . It is not required. It is multivalued, mutable, and returned by default.¶ - irk:
-
A string value that specifies the IRK, which is unique to each device. It is used to resolve a private random address. It should only be provisioned when isRandom is true. It is mutable and never returned. For more information about the use of the IRK, see Volume 1, Part A, Section 5.4.5 of [BLE54].¶
- mobility:
-
A boolean attribute to enable BLE device mobility. If set to true, the device could be expected to move within a network of Access Points (APs). For example, if a BLE device is connected with AP-1 and moves out of range but comes in range of AP-2, it will be disconnected with AP-1 and connected with AP-2. It is returned by default and mutable.¶
7.1.2. Multivalued Attributes
- versionSupport:
-
A multivalued set of strings that specifies the BLE versions supported by the device in the form of an array, for example, ["4.1", "4.2", "5.0", "5.1", "5.2", "5.3", "5.4"]. It is required, mutable, and returned by default.¶
- pairingMethods:
-
A multivalued set of strings that specifies pairing methods associated with the BLE device. The pairing methods may require subattributes such as key/password for the device pairing process. To enable the scalability of pairing methods in the future, they are represented as extensions to incorporate various attributes that are part of the respective pairing process. Pairing method extensions are nested inside the BLE extension. It is required, case sensitive, mutable, and returned by default.¶
7.1.3. BLE Pairing Method Extensions
The details on pairing methods and their associated attributes are in Volume 1, Part A, Section 5.2.4 of [BLE54]. This memo defines extensions for four pairing methods that are nested inside the BLE extension schema. Each extension contains the common attributes in Section 2.1. These extensions are as follows:¶
- pairingNull extension:
-
Identified using the following schema URI:¶
urn
:ietf :params :scim :schemas :extension :pairing Null :2 .0 :Device¶ pairingNull does not have any attribute. It allows pairing for BLE devices that do not require a pairing method.¶
- pairingJustWorks extension:
-
Identified using the following schema URI:¶
urn
:ietf :params :scim :schemas :extension :pairing Just Works :2 .0 :Device¶ The Just Works pairing method does not require a key to pair devices. For completeness, the key attribute is included and is set to 'null'. The key attribute is required, immutable, and returned by default.¶
- pairingPassKey extension:
-
Identified using the following schema URI:¶
urn
:ietf :params :scim :schemas :extension :pairing Pass Key :2 .0 :Device¶ The passkey pairing method requires a 6-digit key to pair devices. This extension has one singular integer attribute, "key", which is required, mutable, and returned by default. The key pattern is as follows:¶
- pairingOOB extension:
-
Identified using the following schema URI:¶
urn
:ietf :params :scim :schemas :extension :pairing OOB :2 .0 :Device¶ The out-of-band (OOB) pairing method includes three singular attributes: key, randomNumber, and confirmation
Number .¶ - key:
-
A string value that is required and received from out-of-band sources such as Near Field Communication (NFC). It is case sensitive, mutable, and returned by default.¶
- randomNumber:
-
An integer that represents a nonce added to the key. It is a required attribute. It is mutable and returned by default.¶
- confirmation
Number : -
An integer that some solutions require in a RESTful message exchange (where RESTful refers to the Representationa
l State Transfer (REST) architecture). It is not required. It is mutable and returned by default if it exists.¶
- Legend:
- sepBroadcastAdd = separate
Broadcast Address, Req = Required, T = True, F = False, RW = ReadWrite, WO = WriteOnly, Def = Default, Nev = Never, Manuf = Manufacturer¶
Example:¶
In the above example, the pairing method is "pairing
Example:¶
However, a device can have more than one pairing method. Support for multiple pairing methods is also provided by the multivalued attribute pairingMethods. In the example below, the BLE device can pair with both passkey and OOB pairing methods.¶
Example:¶
7.2. Wi-Fi Easy Connect Extension
This section describes a schema that extends the device schema to enable Wi-Fi Easy Connect (otherwise known as Device Provisioning Protocol (DPP)). Throughout this specification, we use the term "DPP". The extension is identified using the following schema URI:¶
urn
The attributes in this extension are adopted from [DPP2]. The attributes are as follows.¶
7.2.1. Singular Attributes
- dppVersion:
-
An integer that represents the version of DPP the device supports. This attribute is required, case insensitive, mutable, and returned by default.¶
- bootstrapKey:
-
A string value representing an Elliptic Curve Diffie-Hellman (ECDH) public key. The base64-encoded lengths for P-256, P-384, and P-521 are 80, 96, and 120 characters. This attribute is required, case sensitive, write only, and never returned.¶
- device
Mac Address : -
A MAC address stored as a string. It is a unique 48-bit value. This attribute is optional, case insensitive, mutable, and returned by default. Its form is identical to that of the device
Mac Address for BLE devices.¶ - serialNumber:
-
An alphanumeric serial number stored as a string. It may also be passed as bootstrapping information. This attribute is optional, case insensitive, mutable, and returned by default.¶
7.2.2. Multivalued Attributes
- bootstrapping
Method : -
One or more strings of all the bootstrapping methods available on the enrollee device, for example, [QR, NFC]. This attribute is optional, case insensitive, mutable, and returned by default.¶
- classChannel:
-
One or more strings representing the global operating class and channel shared as bootstrapping information. It is formatted as class/channel, for example, ['81
/1','115 /36'] . This attribute is optional, case insensitive, mutable, and returned by default.¶
- Legend:
- Req = Required, T = True, F = False, RW = ReadWrite, WO = WriteOnly, Def = Default, Nev = Never, Manuf = Manufacturer¶
Example:¶
7.3. Ethernet MAB Extension
This extension enables a legacy means of (very) weak authentication, known as MAC Authenticated Bypass (MAB), that is supported in many wired ethernet solutions. If the MAC address is known, then the device may be permitted (perhaps limited) access. The extension is identified by the following URI:¶
urn
Note that this method is not likely to work properly with MAC address randomization.¶
7.4. FIDO Device Onboard Extension
This extension specifies a voucher to be used by the FDO Device Onboard (FDO) protocols [FDO11] to complete a trusted transfer of ownership and control of the device to the environment. The SCIM server MUST know how to process the voucher, either directly or by forwarding it along to an owner process as defined in the FDO specification. The extension is identified using the following schema URI:¶
urn
7.4.1. Single Attribute
This extension has a singular attribute:¶
- Legend:
- Req = Required, T = True, F = False, WO = WriteOnly, Nev = Never¶
Example:¶
7.5. Zigbee Extension
This section describes a schema that extends the device schema to enable the provisioning of Zigbee devices [Zigbee]. The extension is identified using the following schema URI:¶
urn
It has one singular attribute and one multivalued attribute. The attributes are as follows.¶
7.5.1. Singular Attribute
- device
Eui64Address : -
A 64-bit Extended Unique Identifier (EUI-64) device address stored as string. This attribute is required, case insensitive, mutable, and returned by default. It takes the same form as the device
Mac Address in the BLE extension.¶
7.5.2. Multivalued Attribute
- versionSupport:
-
One or more strings of all the Zigbee versions supported by the device, for example, [3.0]. This attribute is required, case insensitive, mutable, and returned by default.¶
- Legend:
- Req = Required, T = True, F = False, RW = ReadWrite, Def = Default¶
Example:¶
7.6. The Endpoint Applications Extension Schema
Sometimes non-IP devices such as those using BLE or Zigbee require an application gateway interface to manage them.¶
endpointAppsExt provides the list of applications that connect to an enterprise gateway. endpointAppsExt has one multivalued attribute and two singular attributes. The extension is identified using the following schema URI:¶
urn
7.6.1. Singular Attributes
- device
Control Enterprise Endpoint : -
A string representing the URL of the enterprise endpoint to reach the enterprise gateway. When the enterprise receives the SCIM object from the onboarding application, it adds this attribute to it and sends it back as a response to the onboarding application. This attribute is required, case sensitive, read-only, and returned by default. The uniqueness is enforced by the enterprise.¶
- telemetry
Enterprise Endpoint : -
A string representing a URL of the enterprise endpoint to reach an enterprise gateway for telemetry. When the enterprise receives the SCIM object from the onboarding application, it adds this attribute to it and sends it back as a response to the onboarding application. This attribute is optional, case sensitive, read-only, and returned by default. The uniqueness is enforced by the enterprise. This attribute is populated when the enterprise provides a telemetry endpoint (e.g., hosted by the enterprise gateway). If a telemetry service is not known by the SCIM server, the attribute will not be returned. In such cases, if the application requires telemetry, separate arrangements must be made.¶
7.6.2. Multivalued Attribute
- applications:
-
A multivalued attribute of one or more complex attributes that represent a list of endpoint applications, i.e., deviceControl and telemetry. Each entry in the list comprises two attributes including "value" and "$ref".¶
- value:
-
A string containing the identifier of the endpoint application formatted as a Universally Unique Identifier (UUID). It is the same as the common attribute "$id" of the resource EndpointApp. It is read/write, required, case insensitive, and returned by default.¶
- $ref:
-
A reference to the respective EndpointApp resource object stored in the SCIM server. It is readOnly, required, case sensitive, and returned by default.¶
- Legend:
- dev
Cont Ent Endpoint = device Control Enterprise Endpoint, telEntEndpoint = telemetry Enterprise Endpoint, Req = Required, T = True, F = False, RO = ReadOnly, RW = ReadWrite, Ent = Enterprise, Def = Default¶
Example:¶
The schema for the endpointAppsExt extension along with BLE extension is presented in JSON format in Appendix A.9, while the OpenAPI representation is provided in Appendix B.8.¶
8. Security Considerations
Because provisioning operations permit device access to a network, each SCIM client MUST be appropriately authenticated.¶
8.1. SCIM Operations
An attacker that has authenticated to a trusted SCIM client could manipulate portions of the SCIM database. To be clear on the risks, we specify each operation below.¶
8.2. Object Deletion
Once granted, even if the object is removed, the server may or may not act on that removal. The deletion of the object is a signal of intent by the application that it no longer expects the device to be on the network. It is strictly up to the SCIM server and its back end policy to decide whether or not to revoke access to the infrastructure. It is RECOMMENDED that SCIM delete operations trigger a workflow in accordance with local network policy.¶
8.3. Read Operations
Read operations are necessary in order for an application to sync its state to know what devices it is expected to manage. An attacker with access to SCIM objects may gain access to the devices themselves. To prevent one SCIM client from interfering with devices that it has no business managing, only clients that have created objects or those they authorize SHOULD have the ability to read those objects.¶
8.4. Update Operations
Update operations may be necessary if a device has been modified in some way. Attackers with update access may be able to disable network access to devices or device access to networks. To avoid this, the same access control policy for read operations is RECOMMENDED here.¶
8.5. Higher Level Protection for Certain Systems
Devices provisioned with this model may be completely controlled by the administrator of the SCIM server, depending on how those systems are defined. For instance, if BLE passkeys are provided, the device can be connected to, and perhaps paired with. If the administrator of the SCIM client does not wish the network to have complete access to the device, the device itself MUST support finer levels of access control and additional authentication mechanisms. Any additional security must be provided at higher application layers. For example, if client applications wish to keep private information to and from the device, they should encrypt that information over-the-top.¶
9. IANA Considerations
9.1. New Schemas
IANA has added the following additions to the "SCIM Schema URIs for Data Resources" registry:¶
9.2. Device Schema Extensions
IANA has created the following extensions in the "SCIM Server-Related Schema URIs" registry (omitting the "Resource Type" field) as described in Section 7:¶
- Schema URI:
- urn
:ietf :params :scim :schemas :extension :ble :2 .0 :Device¶ - Name:
- BLE Extension¶
- Resource Type:
- Device¶
- Reference:
- RFC 9944, Section 7.1¶
- Schema URI:
- urn
:ietf :params :scim :schemas :extension :ethernet -mab :2 .0 :Device¶ - Name:
- Ethernet MAB¶
- Resource Type:
- Device¶
- Reference:
- RFC 9944, Section 7.3¶
- Schema URI:
- urn
:ietf :params :scim :schemas :extension :fido -device -onboard :2 .0 :Device¶ - Name:
- FIDO Device Onboard¶
- Resource Type:
- Device¶
- Reference:
- RFC 9944, Section 7.4¶
- Schema URI:
- urn
:ietf :params :scim :schemas :extension :dpp :2 .0 :Device¶ - Name:
- Wi-Fi Easy Connect¶
- Resource Type:
- Device¶
- Reference:
- RFC 9944, Section 7.2¶
- Schema URI:
- urn
:ietf :params :scim :schemas :extension :endpoint Apps Ext :2 .0 :Device¶ - Name:
- Application Endpoint Extension¶
- Resource Type:
- Device¶
- Reference:
- RFC 9944, Section 7.6¶
- Schema URI:
- urn
:ietf :params :scim :schemas :extension :pairing Just Works :2 .0 :Device¶ - Name:
- Just Works Auth BLE¶
- Resource Type:
- Device¶
- Reference:
- RFC 9944, Section 7.1.3¶
- Schema URI:
- urn
:ietf :params :scim :schemas :extension :pairing OOB :2 .0 :Device¶ - Name:
- Out-of-Band Pairing for BLE¶
- Resource Type:
- Device¶
- Reference:
- RFC 9944, Section 7.1.3¶
- Schema URI:
- urn
:ietf :params :scim :schemas :extension :pairing Pass Key :2 .0 :Device¶ - Name:
- Passkey Pairing for BLE¶
- Resource Type:
- Device¶
- Reference:
- RFC 9944, Section 7.1.3¶
- Schema URI:
- urn
:ietf :params :scim :schemas :extension :pairing Null :2 .0 :Device¶ - Name:
- Pairing Null¶
- Resource Type:
- Device¶
- Reference:
- RFC 9944, Section 7.1.3¶
- Schema URI:
- urn
:ietf :params :scim :schemas :extension :zigbee :2 .0 :Device¶ - Name:
- Zigbee¶
- Resource Type:
- Device¶
- Reference:
- RFC 9944, Section 7.5¶
10. References
10.1. Normative References
- [BLE54]
-
Bluetooth SIG, "Bluetooth Core Specification", Version 5.4, , <https://
www >..bluetooth .org /Doc Man /handlers /Download Doc .ashx ?doc _id =587177 - [DPP2]
-
Wi-Fi Alliance, "Wi-Fi Easy Connect Specification", Version 3.0, , <https://
www >..wi -fi .org /system /files /Wi -Fi _Easy _Connect _Specification _v3 .0 .pdf - [ECMA]
-
ECMA International, "ECMAScript(R) 2025 Language Specification", ECMA-262, 16th Edition, , <https://
ecma >.-international .org /publications -and -standards /standards /ecma -262 / - [FDO11]
-
FIDO Alliance, "FIDO Device Onboard Specification 1.1", Proposed Standard, , <https://
fidoalliance >..org /specs /FDO /FIDO -Device -Onboard -PS -v1 .1 -20220419 /FIDO -Device -Onboard -PS -v1 .1 -20220419 .html - [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC4648]
-
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10
.17487 , , <https:///RFC4648 www >..rfc -editor .org /info /rfc4648 - [RFC5280]
-
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10
.17487 , , <https:///RFC5280 www >..rfc -editor .org /info /rfc5280 - [RFC7643]
-
Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Core Schema", RFC 7643, DOI 10
.17487 , , <https:///RFC7643 www >..rfc -editor .org /info /rfc7643 - [RFC7644]
-
Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Protocol", RFC 7644, DOI 10
.17487 , , <https:///RFC7644 www >..rfc -editor .org /info /rfc7644 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [RFC8520]
-
Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Description Specification", RFC 8520, DOI 10
.17487 , , <https:///RFC8520 www >..rfc -editor .org /info /rfc8520 - [Zigbee]
-
Zigbee Alliance, "Zigbee Specification", ZigBee Document 05-3474-21, , <https://
zigbeealliance >..org /wp -content /uploads /2019 /11 /docs -05 -3474 -21 -0csg -zigbee -specification .pdf
10.2. Informative References
- [JSONSchema]
-
Wright, A., Ed., Andrews, H. A., Ed., Hutton, B., Ed., and G. Dennis, "JSON Schema: A Media Type for Describing JSON Documents", , <https://
json >.-schema .org /draft /2020 -12 /json -schema -core - [NIPC]
-
Brinckman, B., Mohan, R., and B. Sanford, "An Application Layer Interface for Non
-Internet , Work in Progress, Internet-Draft, draft-Connected Physical Components (NIPC)" -ietf , , <https://-asdf -nipc -19 datatracker >..ietf .org /doc /html /draft -ietf -asdf -nipc -19 - [OAUTHv2]
-
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10
.17487 , , <https:///RFC6749 www >..rfc -editor .org /info /rfc6749 - [OpenAPI]
-
Swagger, "OpenAPI Specification", Version 3.1.1, , <https://
swagger >..io /specification / - [RFC6241]
-
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10
.17487 , , <https:///RFC6241 www >..rfc -editor .org /info /rfc6241 - [RFC7950]
-
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10
.17487 , , <https:///RFC7950 www >..rfc -editor .org /info /rfc7950 - [RFC8040]
-
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10
.17487 , , <https:///RFC8040 www >..rfc -editor .org /info /rfc8040 - [RFC8792]
-
Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10
.17487 , , <https:///RFC8792 www >..rfc -editor .org /info /rfc8792 - [RFC8995]
-
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10
.17487 , , <https:///RFC8995 www >..rfc -editor .org /info /rfc8995
Appendix B. OpenAPI Representation
The following sections are provided for informational purposes.¶
B.1. Core Device Schema OpenAPI Representation
OpenAPI representation of core device schema is as follows:¶
B.2. EndpointApp Schema OpenAPI Representation
OpenAPI representation of EndpointApp schema is as follows:¶
B.3. BLE Extension Schema OpenAPI Representation
OpenAPI representation of BLE extension schema is as follows:¶
B.4. DPP Extension Schema OpenAPI Representation
OpenAPI representation of DPP extension schema is as follows:¶
B.5. Ethernet MAB Extension Schema OpenAPI Representation
OpenAPI representation of Ethernet MAB extension schema is as follows:¶
B.6. FDO Extension Schema OpenAPI Representation
OpenAPI representation of FDO extension schema is as follows:¶
B.7. Zigbee Extension Schema OpenAPI Representation
OpenAPI representation of Zigbee extension schema is as follows:¶
B.8. endpointAppsExt Extension Schema OpenAPI Representation
OpenAPI representation of endpointAppsExt extension schema is as follows:¶
Appendix C. FIDO Device Onboarding Example Flow
The following diagrams are included to demonstrate how FDO can be used. In this first diagram, a device is onboarded not only to the device owner process but also to the AAA server for initial onboarding. The voucher contains a device certificate that is used by the AAA system for authentication.¶
After this flow is complete, the device can then first provisionally onboard and then later receive a trust anchor through FDO's Transfer Ownership Protocol 2 (TO2) process. This is shown below.¶
Acknowledgments
The authors would like to thank Sriram Sekar, Bart Brinckman, Rohit Mohan, Lars Streubesand, Christian Amsüss, Jason Livingwood, Mike Ounsworth, Monty Wiseman, Geoffrey Cooper, Paulo Jorge N. Correia, Phil Hunt, and Elwyn Davies for their reviews and Nick Ross for his contribution to the appendix.¶