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

Draft
wants to merge 15 commits into
base: main
Choose a base branch
from
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` 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
15 changes: 15 additions & 0 deletions docs/attributes-registry/authentication.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
<!--- Hugo front matter used to generate the website version of this page:
--->

<!-- NOTE: THIS FILE IS AUTOGENERATED. DO NOT EDIT BY HAND. -->
<!-- see templates/registry/markdown/attribute_namespace.md.j2 -->

# Authentication

## Authentication Attributes
Copy link
Member

@joaopgrassi joaopgrassi Oct 29, 2024

Choose a reason for hiding this comment

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

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


"Describes the authentication information of an authenticated user."

| Attribute | Type | Description | Examples | Stability |
| ------------------- | ------ | --------------------------------------------------------- | -------------------------------------------------- | ---------------------------------------------------------------- |
| `authentication.id` | 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) |
11 changes: 6 additions & 5 deletions docs/attributes-registry/enduser.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,12 +6,13 @@

# 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-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 | Identifier of an 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-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. |
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.

35 changes: 35 additions & 0 deletions model/enduser/registry.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
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

@MSNev MSNev Oct 21, 2024

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

how about enduser.unauthenticated.id?

Copy link
Contributor

Choose a reason for hiding this comment

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

  • enduser.pseudo.id

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

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?

type: string
stability: experimental
brief: >
Identifier of an 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.
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