The direct answer
Treat a human-readable label and the trusted object ID as separate fields. Choose and version the label’s normalization, comparison and ambiguity policy, then authorize operations against the exact object ID from authenticated application context.
Define the label and identity contract separately
An assistant is asked to open “Café Demo.” The application may receive the accented letter as one character or as a letter followed by a combining mark. A similar-looking name may also belong to another object. Choosing a transformation that makes strings comparable does not decide which object the user may access.
This guide proposes a fictional workspace-label policy. Its novelty is the admission, comparison and display contract, rather than another general instruction to validate IDs. All examples and acceptance checks are PROPOSED_UNRUN. No normalization engine, confusable detector, account, real workspace label, model or authorization boundary was exercised.
Keep normalization, case and confusability distinct
Unicode UAX #15 defines canonical and compatibility normalization. NFC composes canonical equivalents where appropriate; NFKC additionally removes compatibility distinctions. The annex cautions against applying compatibility normalization indiscriminately to arbitrary text. The right choice depends on the field's purpose.
Decide case handling separately. A case-sensitive label index, a case-insensitive search suggestion and an authorization key are different contracts. Do not silently lowercase, trim or remove accents because two strings seem inconvenient to compare.
Unicode UTS #39 describes confusable-detection mechanisms. Its skeleton mappings are for internal comparison, not display or a replacement normalization for identifiers. Similarity can justify a review decision; it cannot establish shared ownership. Fonts and rendering also affect apparent similarity, so “looks identical” is not a stable authorization rule.
Choose a concrete fictional application profile
For this example, the service assigns immutable IDs such as ws_7Q2M9A. Its fixture ID format is the exact ASCII prefix ws_ followed by six uppercase ASCII letters or digits. IDs are not secrets. The application checks the actor's current permission for the exact ID; it never derives an ID by rewriting a label.
The human-facing field uses this proposed profile:
- Decode a valid Unicode scalar sequence, normalize the candidate label to NFC, then apply a limit of 1–48 scalar values. This is not a limit of 48 visible characters.
- Reject C0 controls U+0000–U+001F, DEL U+007F, and leading or trailing ASCII spaces with a field error. Do not repair them silently. This small fixture profile is not a complete production text policy.
- Compare stored label keys by exact, case-sensitive NFC value within one workspace namespace. Use a matching database comparison and an atomic uniqueness constraint, rather than a check followed by an unprotected insert.
- Keep confusable-name review separate. A flagged candidate remains pending until the application's declared review policy resolves it. Record the detector/data version and any profile changes; do not claim UTS #39 conformance from a few examples.
A real product must define any additional script, format-control or bidirectional-text policy for its audience. This fixture does not justify excluding all non-ASCII names. It deliberately retains a valid accented-label control.
Inspect an original representation and decision matrix
These escaped JSON strings make the intended code points inspectable without relying on a font. Each row below is an independent proposed case under the fictional profile.
{
"composed": "Caf\u00e9 Demo",
"decomposed": "Cafe\u0301 Demo",
"width_variant": "\uff24\uff25\uff2d\uff2f-A",
"latin_label": "DEMO-A",
"greek_alpha_label": "DEMO-\u0391"
}| Case | Representation or admission expectation | Application decision |
|---|---|---|
| New Café Demo, no collision | Valid accented NFC label | Admit after required review; assign a new trusted ID |
| Decomposed Cafe plus U+0301 when composed label exists | Same NFC key | Report a name collision; do not merge objects or grants |
| Full-width DEMO versus ASCII DEMO | NFC retains the width distinction | Review possible confusion; do not silently apply NFKC |
| DEMO-A versus DEMO followed by Greek U+0391 | Not the same NFC label | Review the lookalike pair; never infer identity |
| Café Demo versus CAFÉ DEMO | Distinct keys under this case-sensitive policy | Disambiguate any suggestions by authorized object ID |
| Leading ASCII space or a tab in the candidate | Fails this admission policy | Return a field error without continuing with a repaired target |
| Model supplies a matching label with an unauthorized ID | Readable label does not establish authority | Deny access without revealing another object's details |
| Full-width characters substituted into the ASCII ID | Fails the exact ID format | Reject; do not normalize it into an existing ID |
Keep search and display from choosing authority
Search may offer normalized or case-insensitive suggestions if that feature has its own documented policy. Return only candidates the actor is allowed to see. If more than one candidate remains, let the user select an explicit permitted object rather than taking the first approximate match.
Show a readable label alongside a stable ID or other safe disambiguating context where the decision matters. The receiving operation should use the selected ID and recheck current authorization. A model-generated explanation that two labels are equivalent cannot replace that check.
For existing duplicate or ambiguous records, preserve their separate IDs and permissions while resolving the naming conflict. A new comparison profile must not silently combine accounts, workspace records or grants. A reviewed rename is a different operation from changing authorization identity.
Pin the evidence and runtime boundary
The sources inspected for this guide were UAX #15 revision 58 and UTS #39 revision 34, both for Unicode 18.0.0. UAX #15 specifies normalization stability conditions for assigned characters; UTS #39 warns that its security data and stored derived indexes can change between versions. Do not treat the two versioning contracts as identical.
Before a real acceptance run, record the normalization implementation, supported Unicode data, confusable library/data, database collation, profile revision and relevant display environment. The runtime is untested here. A few local string comparisons would establish only those recorded transformations, not a real authorization bypass or complete confusable coverage.
Boundary's planned request router does not implement this label registry or identity policy. Its eight mock policy checks are separate evidence. A future release claim should describe the actual profile and identity boundary verified, including unresolved cases.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.