Add authentication sub-namespace to user #1146
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| # 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: user | ||
|
|
||
| # A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). | ||
| note: introduce subnamespace `user.authentication` with a new attribute `user.authentication.id` | ||
|
|
||
| # 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: Update `identity` attributes under general attribute doc. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -10,13 +10,20 @@ | |
|
|
||
| Describes information about the user. | ||
|
|
||
| | Attribute | Type | Description | Examples | Stability | | ||
| | ------------------------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | ---------------------------------------------------------------- | | ||
| | `user.authentication.id` | string | Unique identifier of an authenticated user in the system. [1] | `S-1-5-21-202424912787-2692429404-2351956786-1000` |  | | ||
| | `user.email` | string | User email address. | `[email protected]` |  | | ||
| | `user.full_name` | string | User's full name | `Albert Einstein` |  | | ||
| | `user.hash` | string | Unique user hash to correlate information for a user in anonymized form. [2] | `364fc68eaf4c8acec74a4e52d7d1feaa` |  | | ||
| | `user.id` | string | Identifies a user interacting with a system regardless of user authentication status. This identifier may be unique only through best-effort means. [3] | `QdH5CAWJgqVT4rOr0qtumf` |  | | ||
| | `user.name` | string | Short name or login/username of the user. | `a.einstein` |  | | ||
| | `user.roles` | string[] | Array of user roles at the time of the event. | `["admin", "reporting_user"]` |  | | ||
|
|
||
| **[1]:** The `user.authentication.id` MAY be used to identify a user attempting to authenticate if it's known at this stage. | ||
|
|
||
| **[2]:** Useful if `user.authentication.id` or `user.name` contain confidential information and cannot be used. | ||
|
|
||
| **[3]:** The `user.id`, when populated, is expected to be generated before user is authenticated and SHOULD NOT change after the user logs in. In browser scenarios `user.id` is usually stored in cookies. | ||
| It's NOT RECOMMENDED to populate this attribute when unauthenticated users are not tracked or identified by the system. | ||
| It can be a random guid or a hash of the user's IP address. This is different from `user.hash` which is a hash of a known `user.authentication.id` or `user.name`. | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -22,14 +22,28 @@ groups: | |
| brief: > | ||
| Unique user hash to correlate information for a user in anonymized form. | ||
| note: > | ||
| Useful if `user.authentication.id` or `user.name` contain confidential information and cannot be used. | ||
| examples: ['364fc68eaf4c8acec74a4e52d7d1feaa'] | ||
| - id: user.id | ||
| type: string | ||
| stability: experimental | ||
| brief: > | ||
| Identifies a user interacting with a system regardless of user authentication status. This identifier may be unique only through best-effort means. | ||
| note: > | ||
| The `user.id`, when populated, is expected to be generated before user is authenticated and SHOULD NOT change after the user logs in. | ||
| In browser scenarios `user.id` is usually stored in cookies. | ||
|
|
||
| It's NOT RECOMMENDED to populate this attribute when unauthenticated users are not tracked or identified by the system. | ||
|
|
||
|
|
||
| It can be a random guid or a hash of the user's IP address. This is different from `user.hash` which is a hash of a known `user.authentication.id` or `user.name`. | ||
| examples: ['QdH5CAWJgqVT4rOr0qtumf'] | ||
| - id: user.authentication.id | ||
| type: string | ||
| brief: Unique identifier of an authenticated user in the system. | ||
| note: > | ||
| The `user.authentication.id` MAY be used to identify a user attempting to authenticate if it's known at this stage. | ||
| examples: ['S-1-5-21-202424912787-2692429404-2351956786-1000'] | ||
| stability: experimental | ||
| - id: user.name | ||
| type: string | ||
| stability: experimental | ||
|
|
||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would remove this line, OpenTelemetry should not be making these statement.
As it's up to the application to determine whether or not they want to track the user.id when the user in authenticated. For client applications this is almost ALWAYS required as they will use this to identify the "user" in some random way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why?
we want authenticated user id to always be in the same attribute
user.authentication.id. If you don't have means to track unauthenticated users, you should never populateuser.id.Otherwise how you see people using those attributes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
only authenticated user id can be tracked through
user.authentication.idand everything else is tracked through 'user.id', it can be anonymous, random, pseudo, unauthenticated, unauthorized and etc. can we not make any recommendation how OpenTelemetry customers use this attribute? as long as we have a crystal-clear description, it's up to the users to decide. does it help?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're recommending to use
user.idonly if app has some means to identify them (without authentication),Assuming app has no means to identify users before authentication,
user.idshould not be used.App can identify them by generating guid on every call, that's also a way of identification/tracking.
So from what I can tell this
NOT RECOMMENDEDjust reinforces the description and does not contradict anything you're saying.I want to keep this sentence since I expect people to put things they don't need into
user.idand want to do as much as possible to avoid it. What's the problem in keeping it?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a strong opinion on this; your argument seems valid. let's try to resolve it in Monday's SIG with @MSNev and everyone else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m finding these names a bit confusing, and agree with this:
It seems that unauthenticated/tracking/pseudo user ids are fairly specific to client (browser/mobile) instrumentation, so maybe it’s better to have a more specific name for that concept (and not use
user.idfor it)?