Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 26 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 22 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions .chloggen/add_enduser_authentication_id.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
# Use this changelog template to create an entry for release notes.
#
# If your change doesn't affect end users you should instead start
# your pull request title with [chore] or use the "Skip Changelog" label.

# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
change_type: enhancement

# The name of the area of concern in the attributes-registry, (e.g. http, cloud, db)
component: enduser

# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`).
note: introduce new attribute `enduser.authentication.id`, replace `enduser.id` with `enduser.anonymous.id`, and deprecate `enduser.authentication.role`, and `enduser.authentication.scope`.

# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists.
# The values here must be integers.
issues: [1104]

# (Optional) One or more lines of additional information to render under the primary note.
# These lines will be padded with 2 spaces and then inserted directly into the document.
# Use pipe (|) for multiline entries.
subtext: |
The new attribute `enduser.authentication.id` 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.
1 change: 1 addition & 0 deletions .github/ISSUE_TEMPLATE/bug_report.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -41,6 +41,7 @@ body:
- area:disk
- area:dns
- area:dotnet
- area:enduser
- area:error
- area:event
- area:exception
Expand Down
1 change: 1 addition & 0 deletions .github/ISSUE_TEMPLATE/change_proposal.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,7 @@ body:
- area:disk
- area:dns
- area:dotnet
- area:enduser
- area:error
- area:event
- area:exception
Expand Down
1 change: 1 addition & 0 deletions .github/ISSUE_TEMPLATE/new-conventions.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,7 @@ body:
- area:disk
- area:dns
- area:dotnet
- area:enduser
- area:error
- area:event
- area:exception
Expand Down
12 changes: 7 additions & 5 deletions docs/attributes-registry/enduser.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,12 +6,14 @@

# Enduser

## Deprecated End User Attributes
## End User Attributes

Describes deprecated enduser attributes. Complete enduser namespace has been deprecated
Describes information about the end user, which can be used as a subdomain of browser, client, or user domains.

| Attribute | Type | Description | Examples | Stability |
|---|---|---|---|---|
| <a id="enduser-id" href="#enduser-id">`enduser.id`</a> | string | Deprecated, use `user.id` instead. | `username` | ![Deprecated](https://img.shields.io/badge/-deprecated-red)<br>Replaced by `user.id` attribute. |
| <a id="enduser-role" href="#enduser-role">`enduser.role`</a> | string | Deprecated, use `user.roles` instead. | `admin` | ![Deprecated](https://img.shields.io/badge/-deprecated-red)<br>Replaced by `user.roles` attribute. |
| <a id="enduser-scope" href="#enduser-scope">`enduser.scope`</a> | string | Deprecated, no replacement at this time. | `read:message, write:files` | ![Deprecated](https://img.shields.io/badge/-deprecated-red)<br>Removed. |
| <a id="enduser-anonymous-id" href="#enduser-anonymous-id">`enduser.anonymous.id`</a> | string | 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. | `QdH5CAWJgqVT4rOr0qtumf` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
| <a id="enduser-authentication-id" href="#enduser-authentication-id">`enduser.authentication.id`</a> | string | Unique identifier of an authenticated user in the system. | `S-1-5-21-202424912787-2692429404-2351956786-1000` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
| <a id="enduser-id" href="#enduser-id">`enduser.id`</a> | string | Deprecated, use `enduser.anonymous.id` instead. | `QdH5CAWJgqVT4rOr0qtumf` | ![Deprecated](https://img.shields.io/badge/-deprecated-red)<br>Replaced by `enduser.anonymous.id` attribute. |
| <a id="enduser-role" href="#enduser-role">`enduser.role`</a> | string | Actual/assumed role the client is making the request under extracted from token or application security context. | `admin` | ![Deprecated](https://img.shields.io/badge/-deprecated-red)<br>Removed. |
| <a id="enduser-scope" href="#enduser-scope">`enduser.scope`</a> | string | Scopes or granted authorities the client currently possesses extracted from token or application security context. The value would come from the scope associated with an [OAuth 2.0 Access Token](https://tools.ietf.org/html/rfc6749#section-3.3) or an attribute value in a [SAML 2.0 Assertion](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html). | `read:message, write:files` | ![Deprecated](https://img.shields.io/badge/-deprecated-red)<br>Removed. |
10 changes: 7 additions & 3 deletions docs/general/attributes.md
Original file line number Diff line number Diff line change
Expand Up @@ -396,9 +396,13 @@ These attributes may be used for any operation with an authenticated and/or auth

| Attribute | Type | Description | Examples | [Requirement Level](https://opentelemetry.io/docs/specs/semconv/general/attribute-requirement-level/) | Stability |
|---|---|---|---|---|---|
| [`enduser.id`](/docs/attributes-registry/enduser.md) | string | Deprecated, use `user.id` instead. | `username` | `Recommended` | ![Deprecated](https://img.shields.io/badge/-deprecated-red)<br>Replaced by `user.id` attribute. |
| [`enduser.role`](/docs/attributes-registry/enduser.md) | string | Deprecated, use `user.roles` instead. | `admin` | `Recommended` | ![Deprecated](https://img.shields.io/badge/-deprecated-red)<br>Replaced by `user.roles` attribute. |
| [`enduser.scope`](/docs/attributes-registry/enduser.md) | string | Deprecated, no replacement at this time. | `read:message, write:files` | `Recommended` | ![Deprecated](https://img.shields.io/badge/-deprecated-red)<br>Removed. |
| [`enduser.authentication.id`](/docs/attributes-registry/enduser.md) | string | Unique identifier of an authenticated user in the system. [1] | `S-1-5-21-202424912787-2692429404-2351956786-1000` | `Required` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
| [`enduser.anonymous.id`](/docs/attributes-registry/enduser.md) | string | 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. | `QdH5CAWJgqVT4rOr0qtumf` | `Recommended` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
| [`enduser.id`](/docs/attributes-registry/enduser.md) | string | Deprecated, use `enduser.anonymous.id` instead. | `QdH5CAWJgqVT4rOr0qtumf` | `Recommended` | ![Deprecated](https://img.shields.io/badge/-deprecated-red)<br>Replaced by `enduser.anonymous.id` attribute. |
| [`enduser.role`](/docs/attributes-registry/enduser.md) | string | Actual/assumed role the client is making the request under extracted from token or application security context. | `admin` | `Recommended` | ![Deprecated](https://img.shields.io/badge/-deprecated-red)<br>Removed. |
| [`enduser.scope`](/docs/attributes-registry/enduser.md) | string | Scopes or granted authorities the client currently possesses extracted from token or application security context. The value would come from the scope associated with an [OAuth 2.0 Access Token](https://tools.ietf.org/html/rfc6749#section-3.3) or an attribute value in a [SAML 2.0 Assertion](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html). | `read:message, write:files` | `Recommended` | ![Deprecated](https://img.shields.io/badge/-deprecated-red)<br>Removed. |

**[1] `enduser.authentication.id`:** 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.

<!-- markdownlint-restore -->
<!-- prettier-ignore-end -->
Expand Down
22 changes: 22 additions & 0 deletions model/enduser/common.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
groups:
- id: identity
type: attribute_group
brief: >
These attributes may be used for any operation with an authenticated and/or authorized enduser.
attributes:
- ref: enduser.id
deprecated: Replaced by `enduser.anonymous.id` attribute.
requirement_level: recommended
- ref: enduser.anonymous.id
requirement_level: recommended
- ref: enduser.role
deprecated: "Removed."
requirement_level: recommended
- ref: enduser.scope
deprecated: "Removed."
requirement_level: recommended
- 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.
Comment on lines +18 to +22
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

12 changes: 0 additions & 12 deletions model/enduser/deprecated/common.yaml

This file was deleted.

24 changes: 0 additions & 24 deletions model/enduser/deprecated/registry-deprecated.yaml

This file was deleted.

42 changes: 42 additions & 0 deletions model/enduser/registry.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
groups:
- id: registry.enduser
type: attribute_group
display_name: End User Attributes
brief: >
Describes information about the end user, which can be used as a subdomain of browser, client, or user domains.
attributes:
- id: enduser.id
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like enduser.tracking.id

Copy link
Contributor Author

@heyams heyams Oct 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some examples

messaging.consumer_id: messaging.consumer.id

nesting is used for .
if not, use _

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kind of like these three:

  • enduser.pseudo.id
  • enduser.transient.id
  • enduser.ephemeral.id

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@trisch-me trisch-me Dec 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what were the cons for enduser.unauthenticated.id?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

type: string
deprecated: Replaced by `enduser.anonymous.id` attribute.
stability: experimental
examples: ['QdH5CAWJgqVT4rOr0qtumf']
brief: >
Deprecated, use `enduser.anonymous.id` instead.
- id: enduser.anonymous.id
type: string
stability: experimental
brief: >
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@heyams were those questions addressed during client sig meeting?

Copy link
Contributor Author

@heyams heyams Dec 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, we kind of covered it. cc @MSNev

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you post the answers here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@MSNev MSNev Dec 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • 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.

Copy link
Contributor

@lmolkova lmolkova Jan 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

examples: ['QdH5CAWJgqVT4rOr0qtumf']
- id: enduser.role
heyams marked this conversation as resolved.
Show resolved Hide resolved
type: string
deprecated: "Removed."
stability: experimental
brief: 'Actual/assumed role the client is making the request under extracted from token or application security context.'
examples: 'admin'
- id: enduser.scope
heyams marked this conversation as resolved.
Show resolved Hide resolved
type: string
deprecated: "Removed."
stability: experimental
brief: >
Scopes or granted authorities the client currently possesses extracted from token
or application security context. The value would come from the scope associated
with an [OAuth 2.0 Access Token](https://tools.ietf.org/html/rfc6749#section-3.3)
or an attribute value in a [SAML 2.0 Assertion](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html).
examples: 'read:message, write:files'
- id: enduser.authentication.id
type: string
brief: "Unique identifier of an authenticated user in the system."
examples: [ 'S-1-5-21-202424912787-2692429404-2351956786-1000' ]
stability: experimental
Loading