Uniform Resource Names for Device Identifiers
Extracted elements (22)
DEV URNs are preferred over UUID-based identifiers in constrained environments because UUIDs impose additional requirements on stable storage, real-time clocks, and identifier length that can be prohibitive. UUID-based identifiers are preferred for general-purpose use instead.
Organization-based identifiers (using PEN numbers) can serve as a temporary measure, but long-term use of broadly employed device identifiers should be registered with IETF rather than using the 'org' subtype, to ensure stable and publicly available specifications.
The 'os' and 'ops' subtypes were originally defined in OMA LwM2M but incorporated into this RFC to collect all DEV URN syntaxes in one place; their syntax was also changed to avoid characters disallowed in SenML Name fields.
Using URNs for device identifiers rather than raw octet strings (e.g., 4-byte binary MAC addresses) is preferred because URNs are universally recognized and self-describing, avoiding the need to agree on interpretation. The extra bytes consumed are justified by the flexibility and interoperability gained.
DEV URNs do not use r-, q-, or f-components as defined in RFC 8141. Percent-encoding is not desirable in DEV URNs due to SenML Name field rules (RFC 8428 Section 4.5.1), though this document does not deviate from general URN syntax.
URN-equivalence for DEV URNs is defined per RFC 8141 Section 3.1: two URNs are URN-equivalent if their assigned-name portions are octet-by-octet equal after case normalization of only the URI scheme ('urn') and namespace identifier ('dev'); the remainder is compared case-sensitively. Two DEV URNs may refer to the same entity without being URN-equivalent (e.g., same MAC address in different case).
An implementation of the DEV URN MUST preserve the limitations and behaviors associated with device identifiers. In particular, a device identifier that is intended to be immutable should not become mutable as a part of implementing the DEV URN type.
Implementations are RECOMMENDED to always use lowercase letters where they have a choice in case, to facilitate equivalence checks, unless there is a reason otherwise (e.g., a subtype requiring both cases).
Implementations MAY check the validity of the 8-bit CRC code in 1-Wire ('ow' subtype) DEV URNs.
The DEV URN type SHOULD only be used for hardware-based identifiers that are expected to be persistent.
DEV URNs as long-term stable unique identifiers have privacy implications: they enable correlating information about a specific device over long periods and location tracking. In some systems, identifiers cannot be changed, so they should be used with care per RFC 7721.
The DEV URN namespace uses the namespace identifier 'dev' and defines a hierarchical syntax: 'urn:dev:' followed by a body (macbody, owbody, orgbody, osbody, opsbody, or otherbody) and optional underscore-separated component parts. The syntax is expressed in ABNF per RFC 5234 and RFC 7405.
The 'example' subtype is reserved for use in examples and has no specific requirements beyond the general ABNF. Additional subtypes may be defined in future specifications via Specification Required or IESG Approval.
The 'mac' subtype encodes EUI-64 identifiers as a 16-character lowercase hexadecimal string. MAC-48 addresses are converted by inserting 0xffff after the OUI; EUI-48 addresses use 0xfffe instead.
The 'ops' subtype encodes an organization, product class, and serial number as PEN-product-serial, with optional colon-separated identifiers and underscore-separated components. Originally defined in OMA LwM2M.
The 'org' subtype encodes organization-defined identifiers using a Private Enterprise Number (PEN) followed by a dash and one or more colon-separated identifiers, allowing vendor-specific or experimental device identifiers.
The 'os' subtype encodes an organization serial number as a PEN followed by a dash and a serial number string, with optional colon-separated identifiers and underscore-separated component parts. Originally defined in OMA LwM2M.
The 'ow' subtype encodes a 64-bit 1-Wire device identifier (8-bit family code, 48-bit unique ID, 8-bit CRC) as a 16-character hexadecimal string. The last two characters represent the CRC-8 code.
IANA registered a new URN namespace 'dev' and created a 'DEV URN Subtypes' registry under 'Device Identification' with initial entries: mac, ow, org, os, ops, and example. Additional subtypes require Specification Required or IESG Approval.
DEV URNs represent long-term stable unique identifiers that may enable correlation of device information over time, location tracking, and device-specific vulnerability exploitation. Special care should be taken to avoid leaking identifiers outside of the system intended to use them.
Systems must be designed to account for devices reporting incorrect identifiers (accidentally or maliciously) and for manipulation of identifiers in communications. Integrity protection, trusted devices, and management practices can mitigate these risks. Do not assume DEV URNs are hard to guess.
The full DEV URN ABNF grammar defines devurn = 'urn:dev:' body componentpart, with body variants for mac, ow, org, os, ops, and other subtypes. Hexstrings use only lowercase hex digits; componentpart uses underscore-separated identifiers for device sub-components.