Update enduser domain and add `enduser.authentication.id` #1456

heyams · 2024-10-07T18:12:02Z

model/enduser/registry.yaml

lmolkova · 2024-10-14T17:45:25Z

model/enduser/registry.yaml

+    brief: >
+      Describes information about the end user, which can be used as a subdomain of browser, client, or user domains.
+    attributes:
+      - id: enduser.id


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.

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?

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

I like enduser.tracking.id

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 _

@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?

I kind of like these three:

enduser.pseudo.id

enduser.transient.id

enduser.ephemeral.id

I attended Client SIG this morning,
they also preferred enduser.pseudo.id after going through this list.

what were the cons for enduser.unauthenticated.id?

we have already discussed and agreed to have enduser.authentication.id. authentication as a sub-namespace under enduser. anything that is not under authentication is either unauthenticated or unauthorized or anonymous or some random id.

…s/semantic-conventions into heya/add-enduser-namespace

heyams · 2024-10-23T18:16:53Z

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

trask · 2024-10-23T19:10:22Z

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

docs/attributes-registry/authentication.md

…mespace

trask · 2024-12-02T20:59:46Z

model/enduser/registry.yaml

+          Identifier of an anonymous end user who interacts with a system.
+          This identifier may be unique only through best-effort means and does not imply that the user is authenticated to the system.


meeting notes from semantic convention SIG meeting today:

is this something that OpenTelemetry instrumentation is planning populate, or is this only something that vendor-specific instrumentation is planning to populate?

if it's something that OpenTelemetry instrumentation is planning to populate, what would the implementation look like, e.g. would this be stored in a persistent cookie? would it be stamped onto a specific event?

there is a desire not to add attributes into the semconv repo when only a single vendor has expressed interest in them

there is also a desire not to add attributes into the semconv repo without having any span/event/metric definitions that use them

the recommendation for next steps was to discuss this in the Client SIG

@heyams were those questions addressed during client sig meeting?

yes, we kind of covered it. cc @MSNev

can you post the answers here?

is this something that OpenTelemetry instrumentation is planning populate

Yes, this will be added by instrumentations either directly or indirectly (via a psuedo user manager -- like the Session Manager)

if it's something that OpenTelemetry instrumentation is planning to populate, what would the implementation look like, e.g. would this be stored in a persistent cookie? would it be stamped onto a specific event?

It will need something like the SessionManager implementation to "manager" the lifecycle of this value, some environments would be just to create a simple random value for App start (like Android) while in a browser which is stateless then the "user manager" would most likely use cookies (but it could also use session storage)

there is a desire not to add attributes into the semconv repo when only a single vendor has expressed interest in them

This will not be single vender specific, but it is highly RUM specific

there is also a desire not to add attributes into the semconv repo without having any span/event/metric definitions that use them

It should be available both Spans and Logs, while it could be available for Metrics it's cardinality (because its a random value) should not necessarily be used for metrics...

thanks! a couple of followup questions:

if/when entity (or mutable resource) attributes are available, do you see enduser.pseudo.id as one of those?

are there any specific span or event semantic conventions that we can add enduser.pseudo.id to? or is enduser.pseudo.id hopefully just an entity (or mutable resource) attribute?

I believe we discussed these in the client SIG. I will wait for @MSNev's response.

If/when mutable resources attributes (whether they are entities or shorter lived lifespan resources ) then this (and session) could possibly by represented there.

are there any specific span or event semantic conventions that we can add enduser.pseudo.id to?

No, not specifically as this really is just additional context details.

I believe having a document covering enduser convention as a whole was a critical feedback point.
We're trying to avoid adding attributes without also adding a signal that leverages them.

I'm surprised we don't have any signals to populate these on. Wouldn't we add them on session events?
https://github.com/open-telemetry/semantic-conventions/blob/f7362c7066856ff8591ac461d4e3b31ad7af3a4b/docs/general/session.md

If we're going to just stamp them on all telemetry items, let's document it as an attribute group - this would be the place to describe any additional guidance. This doc has to be updated anyway.

I believe it should cover:

who populates those attributes - would an HTTP instrumentation do it? Distro? End user apps?

when they are populated? Whenever they are known? Is it opt-in? etc

how to populate them - where would I get this information from? There are some mappings in existing docs - are they still relevant?

is user info propagated to other services (currently docs say it should be using baggage)

…mespace

heyams · 2024-12-10T20:39:02Z

it was a false-negative. that link works. how do i ignore this failure?

trask · 2024-12-10T20:49:53Z

it was a false-negative. that link works. how do i ignore this failure?

it's ok, it's not a required check, we're working on resolving the flakiness

trisch-me · 2024-12-11T21:18:41Z

model/enduser/registry.yaml

+    attributes:
+      - id: enduser.id
+        type: string
+        deprecated: Replaced by `enduser.pseudo.id` attribute.


deprecated attributes should be moved from registry to the deprecated section

my understanding is that if the namespace is deprecated, then it will move everything to the deprecated folder.
if some of the attributes are deprecated, then simply use deprecated:. please correct me if I'm wrong. an example will be helpful.

deprecated attributes should be moved to the deprecated folder. E.g. like here https://github.com/open-telemetry/semantic-conventions/blob/main/model/http/deprecated/registry-deprecated.yaml - you can find a bunch of other examples with https://github.com/search?q=repo%3Aopen-telemetry%2Fsemantic-conventions+%22deprecated%3A%22+language%3AYAML&type=code

trask · 2024-12-20T22:29:39Z

model/enduser/common.yaml

+      - ref: enduser.authentication.id
+        requirement_level: required
+        note: >
+          The `enduser.authentication.id` attribute is intended to provide an unique identifier of an authenticated enduser.
+          The deprecated attributes `enduser.authentication.role` and `enduser.authentication.scope` are removed from the enduser registry.


I was thinking that enduser.id would be the normal (authenticated) user id, do I remember that correctly? thanks

#1456 (comment)
we decided to use enduser.authentication.id for the authenticated user id since the beginning of this discussion.

renaming enduser.id to something specific (like enduser.pseudo.id) so that user don't put authenticated user id under this attribute.

can you summarize the reason for using enduser.authentication.id instead of enduser.id?

does this mean we will prohibit future "embedding" of user.id into the enduser.* namespace? or will we have 3 "id" attributes including enduser.id?

github-actions · 2025-01-05T03:21:58Z

This PR was marked stale due to lack of activity. It will be closed in 7 days.

heyams added 4 commits October 7, 2024 11:08

Add authentication to enduser namespace

3e1655f

Fix yamllint

6f858a2

Fix weaver

07cb1eb

Update markdowns

ee0970f

heyams force-pushed the heya/add-enduser-namespace branch from 0a8b0e8 to ee0970f Compare October 7, 2024 19:06

heyams added 2 commits October 7, 2024 12:08

Generate gh issue

38d8687

Fix policies-check and compatibility

b1cdc13

heyams commented Oct 7, 2024

View reviewed changes

model/enduser/registry.yaml Outdated Show resolved Hide resolved

lmolkova mentioned this pull request Oct 14, 2024

Add authentication sub-namespace to user #1146

Closed

lmolkova reviewed Oct 14, 2024

View reviewed changes

Update

068a822

heyams changed the title ~~Update enduser domain and add authentication as a subdomain~~ Update enduser domain and add enduser.authentication.id Oct 22, 2024

heyams changed the title ~~Update enduser domain and add enduser.authentication.id~~ Update enduser domain and add enduser.authentication.id Oct 22, 2024

heyams and others added 8 commits October 22, 2024 16:09

Merge branch 'main' into heya/add-enduser-namespace

e05d7a3

Update changelog

c17bec6

Merge branch 'heya/add-enduser-namespace' of https://github.com/heyam…

0fa3ffc

…s/semantic-conventions into heya/add-enduser-namespace

Update

d0e26d5

Fix yamllint

614a52e

Fix

a499237

Fix trailing spaces

5bfbfe2

Use 'make generate-gh-issue-tempaltes

5f883d0

joaopgrassi requested changes Oct 29, 2024

View reviewed changes

docs/attributes-registry/authentication.md Outdated Show resolved Hide resolved

joaopgrassi mentioned this pull request Oct 29, 2024

areas-downdown-check template is out of date #1509

Closed

heyams added 5 commits November 22, 2024 15:11

Update

13919ed

Merge remote-tracking branch 'upstream/main' into heya/add-enduser-na…

272ded3

…mespace

Update

5c0d6d3

Fix identity not found

ff85999

Update

d626e6c

heyams marked this pull request as ready for review November 22, 2024 23:41

heyams requested review from a team as code owners November 22, 2024 23:41

heyams added 2 commits November 22, 2024 15:44

Fix yamllint

cb32498

Fix backward compat

1c53711

heyams requested a review from joaopgrassi November 26, 2024 19:16

trask reviewed Dec 2, 2024

View reviewed changes

heyams added 4 commits December 10, 2024 12:15

Rename enduser.id to enduser.pseudo.id

51d0c99

Merge remote-tracking branch 'upstream/main' into heya/add-enduser-na…

5d10c08

…mespace

Update md

949bae8

Update

9778890

MSNev approved these changes Dec 11, 2024

View reviewed changes

trisch-me reviewed Dec 11, 2024

View reviewed changes

LikeTheSalad approved these changes Dec 17, 2024

View reviewed changes

trask reviewed Dec 20, 2024

View reviewed changes

github-actions bot added Stale and removed Stale labels Jan 5, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update enduser domain and add `enduser.authentication.id` #1456

Update enduser domain and add `enduser.authentication.id` #1456

heyams commented Oct 7, 2024

lmolkova Oct 14, 2024

heyams Oct 14, 2024

lmolkova Oct 14, 2024

trask Oct 14, 2024

heyams Oct 15, 2024 •

edited

Loading

heyams Oct 28, 2024

trask Nov 26, 2024

heyams Dec 10, 2024

trisch-me Dec 11, 2024 •

edited

Loading

heyams Dec 11, 2024

heyams commented Oct 23, 2024

trask commented Oct 23, 2024

trask Dec 2, 2024

trisch-me Dec 11, 2024

heyams Dec 11, 2024 •

edited

Loading

trask Dec 11, 2024

MSNev Dec 17, 2024

trask Dec 20, 2024

heyams Dec 20, 2024

MSNev Dec 20, 2024 •

edited

Loading

lmolkova Jan 8, 2025 •

edited

Loading

heyams commented Dec 10, 2024

trask commented Dec 10, 2024

trisch-me Dec 11, 2024

heyams Dec 17, 2024

lmolkova Jan 8, 2025

trask Dec 20, 2024

heyams Jan 6, 2025

trask Jan 8, 2025

github-actions bot commented Jan 5, 2025

		Identifier of an anonymous end user who interacts with a system.
		This identifier may be unique only through best-effort means and does not imply that the user is authenticated to the system.

Update enduser domain and add enduser.authentication.id #1456

Are you sure you want to change the base?

Update enduser domain and add enduser.authentication.id #1456

Conversation

heyams commented Oct 7, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

heyams Oct 15, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

trisch-me Dec 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

heyams commented Oct 23, 2024

trask commented Oct 23, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

heyams Dec 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MSNev Dec 20, 2024 • edited Loading

Choose a reason for hiding this comment

lmolkova Jan 8, 2025 • edited Loading

Choose a reason for hiding this comment

heyams commented Dec 10, 2024

trask commented Dec 10, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Jan 5, 2025

Update enduser domain and add `enduser.authentication.id` #1456

Update enduser domain and add `enduser.authentication.id` #1456

heyams Oct 15, 2024 •

edited

Loading

trisch-me Dec 11, 2024 •

edited

Loading

heyams Dec 11, 2024 •

edited

Loading

MSNev Dec 20, 2024 •

edited

Loading

lmolkova Jan 8, 2025 •

edited

Loading