[Rats] Re: EAT profile mechanics: ueid vs sueids for a resettable value, and current practice for profile identifiers

["Mandyam, Giridhar" <[e-mail]>]

Public

For the FDO standard (FIDO Device Onboard – see https://fidoalliance.org/device-onboarding-overview/) we viewed the ueid from the manufacturer to be replaceable with a GUID from the device owner (https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-PS-v2.0-20260402/FIDO-Device-Onboard-PS-v2.0-20260402.html, see Sec. 3.3.9).

In FDO there is no requirement to persist a post-onboarding lifecycle state across factory resets, as the ownership voucher and device credentials may be reset to a manufacturer state.  Section 3.4.4.2 discusses this process but in non-normative text.

Regarding GUID, the standard states: “Specifically, the GUID is intended to be visible to the Owner when the device shipped in a box, perhaps being on the box itself with a bar code, perhaps being on the bill of lading.”  In other words, the permanence of the GUID is within the ownership context.

>> The question is narrow: is the permanence requirement in 4.2.1.1 meant to bite on a value regenerated by a factory reset, or is that within what a UEID may do?
> You should use sueid. The sueid text says "Examples of life-cycle events are change of ownership, factory reset, ..."

I am not disagreeing with Laurence, but I would add that the original question does not provide sufficient detail as to the target implementation.  For instance, does the sueid get retained or wiped in the factory reset operation?  Can a device owner add their own identifier?

-Giri

From: Laurence Lundblade <[e-mail]>
Sent: Sunday, August 30, 2026 10:52 AM
To: Mohamad Khalil Yossif <mohamad=[e-mail]>
Cc: [e-mail]
Subject: [Rats] Re: EAT profile mechanics: ueid vs sueids for a resettable value, and current practice for profile identifiers


You should use sueid. The sueid text says "Examples of life-cycle events are change of ownership, factory reset, ..."

LL


On Aug 30, 2026, at 4:10 AM, Mohamad Khalil Yossif <mohamad=[e-mail]<mailto:mohamad=[e-mail]>> wrote:

1. ueid or sueids for a value that changes on factory reset

draft-yossif-psea profiles an EAT token and puts a per-deployment
value in ueid. The value is re-derived when the device identifier is
regenerated - a factory reset, or on iOS the loss of the Keychain
entry.

Section 4.2.1.1 says a UEID is permanent and MUST NOT change for a
given entity. Section 4.2.2 describes a value that MAY change on
entity life-cycle events, gives factory reset as an example, and lets
a profile specify the triggering events and carry a label.

Read plainly, a per-deployment value that changes on a life-cycle
event is an SUEID and not a UEID. If that is right, I have the wrong
claim rather than the wrong derivation, and I would rather move it
once, deliberately, than ship a revision that leaves the claim
selection wrong.

The question is narrow: is the permanence requirement in 4.2.1.1
meant to bite on a value regenerated by a factory reset, or is that
within what a UEID may do? A one-line view from anyone who was in the
room for 4.2.1 and 4.2.2 settles it.