Update enduser domain and add enduser.authentication.id

[heyams]

Fixes #1104

[lmolkova]

It seems confusing to set enduser.id = "QdH5CAWJgqVT4rOr0qtumf" and enduser.authentication.id = "lmolkova", based on the

https://github.com/open-telemetry/semantic-conventions/pull/1146/files#r1712997369 and https://github.com/open-telemetry/semantic-conventions/pull/1146/files#r1710187141

It'd be more clear if we called this one enduser.tracking.id or enduser.anonymous.id so that people would not put PII there.

[heyams]

per earlier discussion, it seemed that anonymous was confusing to some.
i'm good with enduser.anonymous_id or enduser.tracking_id. neither tracking nor anonymous a namespace, nesting here doesn't seem to follow the naming convention?

[lmolkova]

do you mean that enduser.tracking.id would not follow the naming convention? Why?

[trask]

I like enduser.tracking.id

[heyams]

some examples

semantic-conventions/schemas/1.19.0

Line 32 in d5d2b9d

messaging.consumer_id: messaging.consumer.id

nesting is used for .
if not, use _

[MSNev]

Not that I really want to extend the discussion further, but based on @jsuereth comments and understanding from his perspective, I can see how anonymous could also be misunderstood and given his suggestions of

"user.unknown_id", "anonymous_user.id", "user.unauth_id".

From these comments, I would suggest the unauth_id option, would identify the meaning better as it's not "unknown" but rather than a random (anonymous) identifier for the current enduser which (from a RUM perspective) is persisted for some period of time. As its unlikely that unauth would represent some common (extended) namespace then either _ or . would work.

It's also represents a possible "linkable" identifier, while on it's own it doesn't identify the user, but in conjunction with other attributes it (may) be possible to identify the enduser so from that perspective it's not "truely" anonymous, which I infer is Josh's point on the name.

[jsuereth]

My concerns around anonymous still apply. I don't think the id is really anonymous and can't be considered as such. It's a tracking id, and should be considered sensitive

[heyams]

how about enduser.unauthenticated.id?

[lmolkova]

• enduser.pseudo.id

Let's create a list of options and add pros/cons.

[heyams]

@lmolkova @trisch-me Please review and fill in anything that i may have missed.:

enduser.pseudo.id
- pros: it's clear to know this id is not authenticated
- cons: it might lead to misinterpretation of this id, like it's not a real id, a testing id, a temporary id?

enduser.tracking.id' - pros: it's clear that this id is used to track a particular user. - cons: tracking` may raise privacy concerns, as it implies monitoring user behavior, which could lead to user distrust. it also lacks context of what exactly is being tracked (e.g. user actions, sessions, locations, etc)

enduser.unauth.id
- pros: unauth is short
- cons: unauth is ambiguous, as it can be unauthenticated or unauthorized. additionally, acronym is not a good naming practice and leads to more confusion.

enduser.temp.id or enduser.transient.id
- pros: it suggests that this id is temporary and associated with user who has not been authenticated.
- cons: it lacks context about the id is temporary for what context (e.g. session, authentication)

enduser.unauthenticated.id
- pro: it's clear to indicate an authenticated user.
- cons: it collides with enduser.authentication.id, which can be renamed to enduser.authenticated.id, then it would have been fine?

enduser.anonymous.id
- pros: it's clear that this id is anonymous.
- cons: it can be confusing and lacks context. as long we have a clear documentation, this should be ok?

[heyams]

need some advice with this weaver error, it didn't point to any files that I have modified. it's persisting.

[trask]

need some advice with this weaver error, it didn't point to any files that I have modified. it's persisting.

if you scroll up from there, you'll see:

ℹ Validating: $/home/weaver/target/general/attributes.md
✖ Could not find: identity

which looks related to this file that was deleted in your PR: model/enduser/deprecated/common.yaml

[joaopgrassi]

I think this should be inside enduser.md. If you add it like this, it will introduce a new "area" called authentication which is not what you are doing in this PR. The authentication attributes are inside enduser namespace which is the area. Please move it to enduser.md