6. SCIM EndpointApp Schema
この節では SCIM device schema extensions の RFC 原文を保持し, Device and EndpointApp resource types, BLE, DPP, Ethernet MAB, FDO, Zigbee, endpointAppsExt, JSON Schema, OpenAPI, IANA registrations, security considerations を含めます.
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:ietf:params:scim:schemas:core:2.0:EndpointApp
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:
* a distinguished name that will be present in the certificate
subject field, as described in Section 4.1.2.4 of [RFC5280] or
* a dnsName as part of a subjectAlternateName, as described in
Section 4.2.1.6 of [RFC5280].
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.
+=================+=======+===+=======+=========+========+========+
| Attribute | Multi |Req| Case | Mutable | Return | Unique |
| | Value | | Exact | | | |
+=================+=======+===+=======+=========+========+========+
| applicationType | F |T | F | Imm | Def | None |
+-----------------+-------+---+-------+---------+--------+--------+
| applicationName | F |T | F | RW | Def | None |
+-----------------+-------+---+-------+---------+--------+--------+
| clientToken | F |F | T | RO | Def | None |
+-----------------+-------+---+-------+---------+--------+--------+
| certificateInfo | F |F | F | RW | Def | None |
+-----------------+-------+---+-------+---------+--------+--------+
| rootCA | F |F | T | RW | Def | None |
+-----------------+-------+---+-------+---------+--------+--------+
| subjectName | F |T | T | RW | Def | None |
+-----------------+-------+---+-------+---------+--------+--------+
| groups | T |F | T | RO | Def | n/a |
+-----------------+-------+---+-------+---------+--------+--------+
Table 2: Characteristics of EndpointApp Schema Attributes
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:
<CODE BEGINS>
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:EndpointApp"],
"id": "e9e30dba-f08f-4109-8486-d5c6a3316212",
"applicationType": "deviceControl",
"applicationName": "Device Control App 1",
"certificateInfo": {
"rootCA" : "MIIBIjAN...",
"subjectName": "www.example.com"
},
"meta": {
"resourceType": "EndpointApp",
"created": "2022-01-23T04:56:22Z",
"lastModified": "2022-05-13T04:42:34Z",
"version": "W\/\"a330bc54f0671c9\"",
"location": "https://example.com/v2/EndpointApps/e9e30dba-f08f-\
4109-8486-d5c6a3316212"
}
}
<CODE ENDS>
Figure 4: Endpoint App Example