2.2.121. User Credential Command Class, version 2 [NEVER CERTIFIED]

Warning

THIS COMMAND CLASS VERSION HAS NEVER BEEN CERTIFIED

This command class version has never been implemented and certified by a Z-Wave product. Therefore, this Command Class version definition MAY be updated in a non-backwards compatible manner, or even removed.

Consult with the Z-Wave Alliance Application Work Group if you consider implementing this Command Class version.

The User Credential Command Class, version 2 introduces the Key Locker to add additional flexibility for credential management on supporting nodes.

Version 2 also introduces the DESFire Credential Type to the Credential Capabilities of the supporting node.

The following commands are introduced to retrieve the configuration of the Key Locker, write Key Locker entries and read entry information from the supporting node:

  • Key Locker Capabilities Get

  • Key Locker Capabilities Report

  • Key Locker Entry Set

  • Key Locker Entry Get

  • Key Locker Entry Report

Version 2 additionally introduces integration of the Active Schedule Command Class, version 1 [NEVER CERTIFIED] to the User Credential command class.

\requirement{CC:0083.02.00.11.000}{0}

Setting schedules for User Unique Identifiers is not required. However, if setting schedules for Unique User Identifiers is supported, then they MUST be supported using the Active Schedule Command Class, version 1 [NEVER CERTIFIED] or higher.

Version 2 also introduces the umbrella term User Management to refer to the User Credential and User Code Command Classes.

Nodes supporting version 2 may also advertise support for multiple User Management command classes but enforce use of a single CC once included in a network and utilize a new pathway to migrate user data. New requirements to support migration affect the following commands:

  • User Capabilities Report

Unless otherwise specified, all other commands are unchanged from User Credential Command Class, version 1.

2.2.121.1. Terminology

2.2.121.1.1. Key Locker

Certain credential types require shared system-level data, such as encryption keys or hashes, alongside the specific credential-level data to function properly.

The Key Locker is a logical construct that allows a controlling node to write persistent system-wide User and/or Credential information to a supporting node that is not tied to a specific User or Credential.

The Key Locker structure consists of Entries that behave similarly to a User or Credential. A supporting node will report which enumerated Entry Types it supports, how many slots of each entry are supported within the Locker, and the size of the data that those Entries can hold.

2.2.121.1.2. User Management

This command class, User Code Command Class, version 2, and version 1 of the same are all considered to be in a logical sub-category of command classes known as User Management command classes. While interoperability between all of the User Management command classes is possible, there are additional requirements for nodes that support more than one User Management command class. See User Code Command Class Dependencies and User Management Overview for more information.

2.2.121.2. Compatibility Considerations

2.2.121.2.1. Active Schedule Command Class Dependencies

\requirement{CC:0083.02.00.23.000}{0}

This Command Class MAY be used in conjunction with the Active Schedule Command Class, version 1 [NEVER CERTIFIED] or higher to schedule access for users.

\requirement{CC:0083.02.00.21.001}{0}

All schedule Targets of this CC MUST map Target ID values directly to User Unique Identifiers.

\requirement{CC:0083.02.00.21.002}{0}

Target IDs in get and set operations for Target CC 0x83 from the Active Schedule Command Class, version 1 [NEVER CERTIFIED] MUST be considered valid or invalid based on the same requirements applied to UUIDs, including valid values and number of Users on the node. The number of User Unique Identifiers reported in the User Capabilities Report Command by the end node MUST also equal the number of supported Targets for Target CC 0x83 in the Active Schedule Capabilities Report Command.

\requirement{CC:0083.02.00.21.003}{0}

Schedules attached to Users MUST NOT use Schedule Metadata. All schedule metadata MUST be ignored or set to 0 as appropriate when handling scheduling commands.

Interpreting schedules

A User’s scheduling may be enabled or disabled on a per User basis, handled through the Active Schedule Enable Set Command.

Whether or not a Users’ scheduling is Active depends on which type and how many schedules are attached to the User.

A User’s scheduling is Active by performing a logical operation with the following steps: - Establishing a union (Logical OR) of attached time fences of a specific type - Establishing an intersection of (Logical AND) of those unions, if multiple schedule types are attached to the user.

A user has Daily Repeating Schedules A and B and Year Day Schedules C and D attached - this user’s scheduling is Active if the current node time falls within the combination of time fences such that

(A OR B) AND (C OR D)

is true.

Otherwise, the user’s scheduling is Inactive.

If the User only has one scheduling type, only one attached schedule need be active. If no schedules are active, then the User’s scheduling is inactive.

When a valid credential for this User is entered, and the User is otherwise valid and allowed access to the node:

\requirement{CC:0083.02.00.11.004}{0}

  • If scheduling attached to the user is Enabled and Active, then the node MUST grant access to the user.

\requirement{CC:0083.02.00.11.005}{0}

  • If scheduling attached to the user is Enabled and Inactive, then the node MUST NOT grant access to the user, and MAY instead send a Notification Report Command with Notification Type “Access Control” (0x06), Notification Event “Valid credential access denied due to the User’s schedule being inactive” (0x30), and Event/State parameters containing only Credential Usage Data MUST be sent.

\requirement{CC:0083.02.00.11.006}{0}

If schedules for the user are disabled, the node MUST allow the user 24/7 permanent access to the node with its assigned Credential(s).

2.2.121.2.2. Application Status Command Class Dependencies

\requirement{CC:0083.02.00.21.007}{0}

It is REQUIRED that the Application Status Command Class is also supported by a supporting node if the node also supports User Code Command Class, version 1 or later.

2.2.121.2.3. User Code Command Class Dependencies

A User Code, in the context of cross-functionality with the User Credential Command Class, is a combination of elements of both a User and a PIN code, and difficulties in cross-functionality can arise when a node is capable of supporting a User that does not have PIN codes attached, and/or a User with multiple PIN codes, among other scenarios.

If both User Code Command Class and User Credential Command Class are advertised, then additional requirements for controlling nodes apply. Please refer to User Management Overview for more information.

\requirement{CC:0083.02.00.23.008}{0}

For backwards compatibility considerations, a device MAY advertise support for both the User Code Command Class and User Credential Command Class. However, when the advertised version of the User Credential Command Class is version 2 or later, a node MAY opt to either

  • store its User Management data exclusively either as Users and Credentials (User Credential CC) or as User Codes (User Code CC), or

  • have the two Command Classes share the same database simultaneously.

If multiple User Management command classes are advertised as supported by a supporting node, the following requirements will apply in addition to those previously defined in User Credential Command Class, version 1:

\requirement{CC:0083.02.00.21.009}{0}

A supporting node reports how many database slots are used for Users and how many are used for User Codes based on the number of Users and/or User Codes reported in both the Users Number Report Command and the User Capabilities Report Command.

By advertising that the numbers of supported Users or User Codes are zero, a supporting node can effectively disable user and credential management using the corresponding command class as any set operations require a non-zero User or User Code.

\requirement{CC:0083.02.00.21.010}{0}

The number of reported User Codes and Users supported by the node MUST follow Table 2.567 below.

Table 2.567 Valid Number of Reported Users and User Codes

Number of Supported User Codes

Number of supported Users

Description

Non-zero

Non-zero

Node simultaneously supports User Code and User Credential Command Classes.

Zero

Non-zero

The node’s user management slots are currently occupied by PIN codes and Users, but these can be migrated to User Codes.

Non-zero

Zero

The node’s user management slots are currently occupied by User Codes, but these can be migrated to PIN Codes and Users.

Zero

Zero

Invalid - not allowed.

\requirement{CC:0083.02.00.21.011}{0}

The reported numbers of supported Users and User Codes cannot both be zero - at least ONE User or User Code must be reported.

\requirement{CC:0083.02.00.21.012}{0}

If the number of supported Users and User Codes are both non-zero, the number of supported Users AND PIN code slots in the respective User/Credential Capability Reports MUST equal the number of supported User Codes. In this case, then the command classes are considered to have simultaneous support and all of the interoperability requirements in the User Credential Command Class, version 1 apply.

If the Command Classes are not simultaneously supported, the following interoperability requirements apply instead:

\requirement{CC:0083.02.00.21.013}{0}

It is REQUIRED that the Version Command Class, version 4 is supported for Migration purposes if User Management command classes are not simultaneously supported.

\requirement{CC:0083.02.00.21.014}{0}

If the node only supports either a non-zero number of Users OR a non-zero number of User Codes at a time, then the node MUST at least support migration of User Codes to Users and PIN codes.

\requirement{CC:0083.02.00.23.015}{0}

A Node MAY optionally support backwards migration of Users/PIN Codes to User Codes.

\requirement{CC:0083.02.00.21.016}{0}

The migration process from User Codes to Users and PIN Codes must map all User Codes to new, discrete Users and PIN Codes using the mappings described in Table 2.547.

\requirement{CC:0083.02.00.21.017}{0}

If a preexisting User Code contains characters that are not digits (0-9), these User Codes MUST be deleted during migration, and a corresponding User and PIN code MUST NOT be created.

\requirement{CC:0083.02.00.21.018}{0}

Likewise, the migration process from Users and PIN Codes to User Codes MUST follow Table 2.546 for each PIN code on the migrating node.

Scheduling Migration Considerations

\requirement{CC:0083.02.00.21.019}{0}

If the supporting node advertises support for both Schedule Entry Lock Command Class, version 3 AND Active Schedule Command Class, version 1 [NEVER CERTIFIED] (hereafter simply “User Scheduling command classes”), simultaneous support of User Management command classes is NOT allowed and migration must be used.

By design, schedules defined by the User Scheduling command classes are identical in form. The migration operation will simply reapply the schedule data to the new User or User Code, to be manipulated through their respective scheduling command class.

However, there are a handful of requirements that are necessary to eliminate edge cases - see Terminology and Schedule Entry Lock Command Class, version 3 for more information on definitions.

\requirement{CC:0083.02.00.21.020}{0}

If a User or User Code in question is unable to be migrated, its existing schedules MUST be dropped.

\requirement{CC:0083.02.00.21.021}{0}

Schedule Slot indexes MUST be preserved - For example, User Code 3’s Year Day Schedule slot 2 must be reassigned to the corresponding created User’s Year Day Schedule slot 2 during migration, if that slot exists.

\requirement{CC:0083.02.00.21.022}{0}

If the number of supported Schedules per User is not equal to the number of supported Schedules per User Code of each type, any additional source schedules MUST be dropped, and any extra destination slots MUST be cleared.

2.2.121.3. User Capabilities Report Command

This command is used to report User capabilities and limits from the node.

\requirement{CC:0083.02.02.21.001}{0}

The User Capabilities Report Command MUST be returned in response to this command, even if User Codes are currently in use on the receiving node.

7

6

5

4

3

2

1

0

Command Class = COMMAND_CLASS_USER_CREDENTIAL (0x83)

Command = USER_CAPABILITIES_REPORT (0x02)

Number of supported User Unique Identifiers (MSB)

Number of supported User Unique Identifiers (LSB)

Supported Credential Rules Bit Mask

Max Length of User Name

User Schedule Support

All Users Checksum Support

User Checksum Support

User Name Encoding Support

UTF-16

Extended ASCII

ASCII

Supported User Types Bit Mask Length

Supported User Types Bit Mask 1

…

Supported User Types Bit Mask N

All command fields and definitions are unchanged from Version 1, but additional requirements apply.

User Schedule Support (1 bit)

This field indicates if the sending node supports scheduling access for a User Unique Identifier via the Active Schedule Command Class, version 1 [NEVER CERTIFIED] or higher.

If User Schedule functionality is supported:

\requirement{CC:0083.02.02.11.001}{0}

\requirement{CC:0083.02.02.11.002}{0}

If User Schedule functionality is NOT supported:

\requirement{CC:0083.02.02.11.003}{0}

Number of Supported User Unique Identifiers (16 bits)

\requirement{CC:0083.02.02.23.001}{0}

This field MAY be set to zero ONLY if the supporting node advertises support for User Code Command Class, version 2, the supporting node supports migration per Version Command Class, version 4 and the User Codes on the supporting node have not been migrated to Users as described in Table 2.567.

\requirement{CC:0083.02.02.21.002}{0}

Otherwise, this field MUST NOT be set to zero.

If a supporting node reports this field as 0, then User Codes are currently in use on that node without simultaneous support. Some commands in the User Credential Command Class are still valid with a given UUID of 0, or do not need a UUID.

In this case:

\requirement{CC:0083.02.02.21.003}{0}

  • That supporting node MUST respond with Supervision Fail (or Application Rejected if Supervision is not used) to the following commands, even if they are otherwise valid:

    • User Set

    • User Get

    • Credential Capabilities Get

    • Credential Set

    • Credential Get

    • All Users Checksum Get

    • User Checksum Get

    • Credential Checksum Get

\requirement{CC:0083.02.02.21.004}{0}

\requirement{CC:0083.02.02.22.005}{0}

2.2.121.4. Credential Set Command

This command adds, removes, or modifies Credentials in a node for an existing user.

7

6

5

4

3

2

1

0

Command Class = COMMAND_CLASS_USER_CREDENTIAL (0x83)

Command = CREDENTIAL_SET (0x0A)

User Unique Identifier (MSB)

User Unique Identifier (LSB)

Credential Type

Credential Slot (MSB)

Credential Slot (LSB)

Reserved

Operation Type

Credential Length

Credential Data

Credential Type (8 bits)

\requirement{CC:0083.02.0A.11.000}{0}

The type of this specific Credential. This field MUST comply with Table 2.568.

Table 2.568 Credential Type Encoding (Ver 2)

Value

Name

Definition

0x00

None

Reserved for Next Credential Type in Credential Report

0x01

PIN Code

A numeric code typed in at the node

0x02

Password

Alpha-numeric code typed in at the node

0x03

RFID Code

A numeric code entered over a Radio Frequency ID connection

0x04

BLE

A numeric code entered over a Bluetooth Low energy connection

0x05

NFC

A numeric code entered over a Near Field Communication connection

0x06

UWB

A numeric code entered over an Ultra-Wideband connection

0x07

Eye Biometric

Biometric data relating to the eye(s) such as an iris, retina, or scleral vein which is scanned at the node

0x08

Face Biometric

Biometric data relating to the face which is scanned at the node

0x09

Finger Biometric

Biometric data relating to the finger(s) such as finger geometry or a fingerprint which is scanned at the node

0x0A

Hand Biometric

Biometric data relating to the hand(s) such as a palm print or hand geometry which is scanned at the node

0x0B

Unspecified Biometric

Biometric data that does not fall into other biometric types specified in this Credential Type which is scanned at the node

0x0C

DESFire EV2/3

MIFARE DESFire RFID Credential Format

2.2.121.4.1. MIFARE DESFire Credential Type Requirements

The DESFire credential type utilizes a third-party, multi-purpose RFID credential management IC to transmit secure NFC credentials using a variety of security schema, the specifics of which are dependent on the specific application.

A credential of this type requires 3 pieces of information to operate a node:

  • The data of the RFID card itself that a user would physically carry around. This is the Credential Data, stored in the supporting node’s Credential Database.

  • One or more Application Keys, stored on the supporting node to decrypt the RFID card data. These Application Keys are stored in the Key Locker as Locker Entries, and the Entry ID of the required Key for a given credential is stored alongside the Credential Data of that credential.

  • An Application ID is used by the DESFire chip to further validate the credential. This is stored in alongside its corresponding Application Key information in the Key locker.

Further information on how this credential type is used can be found in [21].

\requirement{CC:0083.02.0A.11.001}{0}

Nodes advertising support for Credential Type 0x0C (DESFire RFID) MUST support at least one (1) Key Locker Entry of type 0x01 (DESFire Application Key).

For both Credential Set and Credential Report commands of DESFire credentials, the following credential data requirements apply:

\requirement{CC:0083.02.0A.11.003}{0}

The first two (2) bytes (indices 0~1) of Credential Data in a Credential Set Command of type DESFire credential MUST contain the specific Locker Entry slot of the DESFire Application Key that is associated with the credential.

\requirement{CC:0083.02.0A.13.001}{0}

These first two bytes MAY be zero if only one Application key is supported.

All other fields and requirements for this command are unchanged from User Credential Command Class, version 1.

2.2.121.5. Key Locker Capabilities Get Command

This command is used to request the capabilities of the Key Locker on the supporting node.

\requirement{CC:0083.02.1D.11.000}{0}

The Key Locker Capabilities Report Command MUST be returned in response to this command.

\requirement{CC:0083.02.1D.11.001}{0}

This command MUST NOT be issued via multicast addressing.

\requirement{CC:0083.02.1D.11.002}{0}

A receiving node MUST NOT return a response if this command is received via multicast addressing. The Z-Wave Multicast frame, the broadcast Node ID and the Multi Channel Multi-End Point destination are all considered multicast addressing methods.

7

6

5

4

3

2

1

0

Command Class = COMMAND_CLASS_USER_CREDENTIAL (0x83)

Command = KEY_LOCKER_CAPABILITIES_GET (0x1D)

2.2.121.6. Key Locker Capabilities Report Command

This command is used to report Key Locker capabilities and limits from the node.

7

6

5

4

3

2

1

0

Command Class = COMMAND_CLASS_USER_CREDENTIAL (0x83)

Command = KEY_LOCKER_CAPABILITIES_REPORT (0x1E)

Number of Supported Entry Types

Supported Entry Type 1

…

Supported Entry Type N

Number of Entry Slots 1 (MSB)

Number of Entry Slots 1 (LSB)

…

Number of Entry Slots N (MSB)

Number of Entry Slots N (LSB)

Min. Length of Entry Data 1 (MSB)

Min. Length of Entry Data 1 (LSB)

…

Min. Length of Entry Data N (MSB)

Min. Length of Entry Data N (LSB)

Max. Length of Entry Data 1 (MSB)

Max. Length of Entry Data 1 (LSB)

…

Max. Length of Entry Data N (MSB)

Max. Length of Entry Data N (LSB)

Number of Supported Entry Types (8 bits)

This field advertises the number of Entry Types supported by the supporting node’s Key Locker, hereafter (in this section) simply referred to as ‘n’.

\requirement{CC:0083.02.1E.13.001}{0}

\requirement{CC:0083.02.1E.11.002}{5}

This field MAY be equal to zero (0), but if so, this MUST signify to the controller that the node does not use the Key Locker functionality, and all Key Locker GET and SET commands MUST be ignored.

\requirement{CC:0083.02.1E.11.003}{0}

This field MUST be followed by the following five blocks of this number each:

  • Entry Type (8 bits * n)

  • Entry Type Support Bitfield (8 bits * n)

  • Number of Supported Entry Slots for Type (16 bits * n)

  • Min Length of Entry Data per Slot for Type fields (16 bits * n)

  • Max Length of Entry Data per Slot for Type fields (16 bits * n)

Supported Entry Type (8 bits)

This field advertises which of the enumerated Entry Types are supported by the node.

\requirement{CC:0083.02.1E.11.004}{0}

The reported values in this field MUST comply with Table 2.569.

Number of Entry Slots (16 bits)

This field advertises the number of slots that can be addressed using the corresponding Entry Type.

\requirement{CC:0083.02.1E.11.009}{0}

This field MUST be greater than zero (0).

Minimum Length of Entry Data (16 bits)

This field advertises the minimum length of data that the entry of the corresponding Entry Type can contain.

Maximum Length of Entry Data (16 bits)

This field advertises the maximum length of data that the entry of the corresponding Entry Type can contain.

\requirement{CC:0083.02.1E.11.010}{0}

This field MUST be greater than or equal to the Minimum Length field above.

2.2.121.7. Key Locker Entry Set Command

This command adds, modifies or deletes data from Key Locker entries on a supporting node.

7

6

5

4

3

2

1

0

Command Class = COMMAND_CLASS_USER_CREDENTIAL (0x83)

Command = KEY_LOCKER_ENTRY_SET (0x1F)

Entry Type

Entry Slot (MSB)

Entry Slot (LSB)

Reserved

Operation Type

Entry Data Length (MSB)

Entry Data Length (LSB)

Entry Data 0

…

Entry Data N

Entry Type (8 bits)

\requirement{CC:0083.02.1F.11.000}{0}

The Entry Type of this entry.

This field MUST comply with Table 2.569.

Table 2.569 Entry Type Encoding

ID

Name

Description

0x01

DESFire EV2/3 Application ID + Key

MiFare DESFire RFID Credential Application Key.

Credential Data MAY be required to be signed and/or encrypted.

The first three (3) bytes (indices 0~2) of the Entry Data MUST contain the MiFare DESFire Application ID corresponding the key being stored in the slot.

\requirement{CC:0083.02.1F.11.001}{0}

All other values are reserved and MUST NOT be used by a sending node, with the exception of 0x00 in a batch delete operation. Reserved values MUST be ignored by a receiving node.

\requirement{CC:0083.02.1F.11.002}{0}

If an Entry Type is specified in this command as one not advertised as supported in the Key Locker Capabilities Report Command, a receiving node MUST ignore the command.

Entry Slot (16 bits)

The Entry Slot is a sixteen (16) bit address that points to where a particular Entry of the given Entry Type is stored.

\requirement{CC:0083.02.1F.11.003}{0}

The range of values MUST be one to Number of Supported Entry Slots for the given Entry Type, inclusive (see Key Locker Capabilities Report Command). Zero is an invalid Entry Slot unless being used in a Delete operation.

\requirement{CC:0083.02.1F.11.004}{0}

If an Entry Slot is specified in this command as one not advertised as supported in the Key Locker Capabilities Report Command for that Entry Type, a receiving node MUST ignore the command.

\requirement{CC:0083.02.1F.11.005}{0}

If an Entry Slot of zero is specified in this command for a non-Delete Operation Type, a receiving node MUST ignore the command.

Entry Slots are unique per Entry Type. For example, Entry Type 2, Slot 1 is distinct from Entry Type 3, Slot 1.

Reserved (6 bits)

\requirement{CC:0083.02.1F.11.006}{0}

This field MUST be set to zero by a sending node and MUST be ignored by a receiving node.

Operation Type (2 bits)

The Operation Type field indicates how the entry data is supposed to change.

\requirement{CC:0083.02.1F.11.007}{0}

This field MUST comply with Table 2.570.

\requirement{CC:0083.02.1F.11.008}{0}

Table 2.570 Key Locker Entry Set::Operation Type

Value

Name

Definition

0x00

Add

Entry Data given in the command is added to the given Entry if the slot is already empty.

Adds to Occupied Entries MUST be rejected. If Supervision is being used, then the node MUST respond with a status of Fail. If Supervision is not being used, then an Application Rejected command MUST be sent instead.

If the Entry is already occupied, and that Entry Data matches the Entry Data given in the command, then the operation MUST still fail with the same behavior as if the new Entry Data is different. This is to prevent another node on the network from adding Entries over and over to an occupied slot with the intention of guessing the Entry Data.

A Key Locker Entry Report Command MUST be sent to the lifeline from the supporting node upon a successful Add operation.

0x01

Modify

Entry Data given in the command overwrites the given Entry if the slot is already occupied.

Modifies to empty Entries MUST be rejected. If Supervision is being used, then the node MUST respond with a status of Fail. If Supervision is not being used, then an Application Rejected command MUST be sent instead.

If the Entry is already occupied, and that Entry Data matches the Entry Data given in the command, then the operation MUST return the same Success response as if the Entry Data was updated. This is to prevent another node on the network from updating an Entry over and over to an occupied slot with the intention of guessing the Entry Data.

A Key Locker Entry Report Command MUST be sent to the lifeline from the supporting node upon a successful Modify operation.

0x02

Delete

One or more Entry Slots are Deleted. The Delete operation also allows for batch operations as described in the following requirements.

The Entry Length and Entry Data fields in this command MUST be ignored. Those MAY be set to default values or not included at all.

If the Entry Type and Entry Slot are non-zero, then that specific Entry Slot is deleted. The receiving node MUST then send a Key Locker Entry Report Command to the lifeline if the Entry was occupied and was successfully deleted.

If the Entry Type is non-zero and the Entry Slot is zero, then all Entry Slots of the given Entry Type are deleted. The receiving node MUST then send a Key Locker Entry Report Command to the lifeline.

If the Entry Type is zero and the Entry Slot is non-zero, then the command MUST be ignored.

If the Entry Type and Entry Slot are both zero, then all entries in the entire Key Locker are deleted. The receiving node MUST then send a Key Locker Entry Report Command to the lifeline.

\requirement{CC:0083.02.1F.11.009}{0}

All other values are reserved and MUST NOT be used by a sending node. Reserved values MUST be ignored by a receiving node.

Entry Data Length (16 bits)

This field contains the length of the following Entry Data, in bytes.

\requirement{CC:0083.02.1F.11.010}{0}

The value of this field MUST be less than or equal to than the Max Length of Entry Data for the specific Entry Type specified in the Key Locker Capabilities Report Command.

\requirement{CC:0083.02.1F.11.011}{0}

The value of this field MUST be greater than or equal to the Min Length of Entry Data for the specific Entry Type specified in the Key Locker Entry Report Command.

\requirement{CC:0083.02.1F.13.012}{0}

The value of this field MAY be zero, or the field MAY be omitted entirely, when performing a Delete operation.

Entry Data (Variable Length)

The Entry data to set for the Entry being added or modified.

\requirement{CC:0083.02.1F.11.013}{0}

The length of this field MUST be equal to the Entry Data Length field above.

\requirement{CC:0083.02.1F.13.014}{0}

This field MAY be omitted when deleting Entries.

2.2.121.8. Key Locker Entry Get Command

This command is used to get information associated with a specific Entry Type and Entry Slot.

\requirement{CC:0083.02.20.11.001}{0}

This command MUST NOT be issued via multicast addressing.

\requirement{CC:0083.02.20.11.002}{0}

A receiving node MUST NOT return a response if this command is received via multicast addressing. The Z-Wave Multicast frame, the broadcast Node ID and the Multi Channel Multi-End Point destination are all considered multicast addressing methods.

7

6

5

4

3

2

1

0

Command Class = COMMAND_CLASS_USER_CREDENTIAL (0x83)

Command = KEY_LOCKER_ENTRY_GET (0x20)

Entry Type

Entry Slot (MSB)

Entry Slot (LSB)

For field descriptions, refer to the Key Locker Entry Set Command.

2.2.121.9. Key Locker Entry Report Command

This command reports changes of, or operation results on, Key Locker entries.

\requirement{CC:0083.02.21.11.001}{0}

If a Key Locker entry is modified from any source, such as a local interface or an additional controlling node, a Key Locker Entry Report command with the affected Entry identifier MUST be sent to the lifeline.

7

6

5

4

3

2

1

0

Command Class = COMMAND_CLASS_USER_CREDENTIAL (0x83)

Command = KEY_LOCKER_ENTRY_REPORT (0x21)

Reserved (7 Bits)

Occupied

Entry Type

Entry Slot (MSB)

Entry Slot (LSB)

For Entry Type and Entry Slot descriptions, see the Key Locker Entry Set Command.

Reserved (7 Bits)

\requirement{CC:0083.02.21.11.002}{0}

This field MUST be set to zero by a sending node and MUST be ignored by a receiving node.

Occupied (1 Bit)

For security reasons, the only information transmitted to a controlling node from a supporting node is whether the given Locker entry contains any data.

\requirement{CC:0083.02.21.11.003}{0}

This field MUST be equal to 1 if the specified Key Locker entry contains data, and MUST be equal to 0 if the Key Locker entry does NOT contain data.