Update enduser domain and add enduser.pseudo.id

[heyams]

Fixes #1104

[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

[heyams]

For people who are flip-flopping on what we discussed about sub namespace authentication, a friendly reminder to revisit these links:

#1104 (comment)
#1104 (comment)

#1172

or watch the SIG meeting recordings whenever i was present :)

[trask]

For people who are flip-flopping on what we discussed about sub namespace authentication, a friendly reminder to revisit these links

hi @heyams, I don't see any arguments in those links for specifically preferring enduser.authenticated.id over enduser.id?

in order to help this PR move forward, can you write out the reasons you have for specifically preferring enduser.authenticated.id over enduser.id? (other than that you thought it was decided already)

[heyams]

For people who are flip-flopping on what we discussed about sub namespace authentication, a friendly reminder to revisit these links

hi @heyams, I don't see any arguments in those links for specifically preferring enduser.authenticated.id over enduser.id?

in order to help this PR move forward, can you write out the reasons you have for specifically preferring enduser.authenticated.id over enduser.id? (other than that you thought it was decided already)

it was decided in the SIG meeting, not me. recording is available though. they preferred to have user.authentication.id (not user.authenticated.id) as sub-namespace, and then there was a concern that user is too ambiguous because user needs to be used along with a parent namespace. Then we decided to bring back enduser and applied the same authentication sub-namespace. Then we had a concern that people might put authenticated user id into the enduser.id field.. that was when I was asked to come up with a list of other names. throughout this renaming discussion, nobody questioned enduser.authentication.id. now we settled with enduser.pseudo.id for enduser.id, we are back to square one, need to revisit whether or not we want enduser.authentication.

[trask]

@heyams I still don't see any reasons in your last comment for specifically preferring enduser.authenticated.id over enduser.id? (other than that you thought it was decided already)

[trisch-me]

hey @heyams

it might be a long thread but I think we all want to see it merged.
We have discussed this issue on semconv meeting this Monday and as @trask mentioned above (and to my personal preference) I am in favor of having just id without additional subdomain. And I don’t see clear preference for the other option.

I remember we have discussed in the beginning that it might be good to have additional sub namespace for authentication attributes and put there id and other attributes, but I think we can start simple without specific subdomain until we have a use case for it.

please let me know if it would work for you
also everyone else please chime in if you think this isn't working for some cases

[heyams]

hey @heyams

it might be a long thread but I think we all want to see it merged. We have discussed this issue on semconv meeting this Monday and as @trask mentioned above (and to my personal preference) I am in favor of having just id without additional subdomain. And I don’t see clear preference for the other option.

I remember we have discussed in the beginning that it might be good to have additional sub namespace for authentication attributes and put there id and other attributes, but I think we can start simple without specific subdomain until we have a use case for it.

please let me know if it would work for you also everyone else please chime in if you think this isn't working for some cases

I was planning to attend the SIG to get everyone's feedback. Monday was a public holiday here. If that was the consensus from everyone from the SIG to reuse enduser.id for the authenticated user id, I'm good with it. I can go ahead to make a change this week and then discuss it further in the next SIG if anyone else objects.

i appreciate that you reach out because this sub-namespace was your original idea.

[trisch-me]

hey @heyams - sure, back then we wanted to find a solution on how to manage both auth and not auth id, and that was one of ideas, but now we have already user.pseudo.id, so I believe we can proceed with just user.id

[trisch-me]

@heyams there are still conflicts not resolved

[MSNev]

Provided comments offline about possible rewording of the description for enduser.pseudo.id specifically to remove the "reveal" wording. But this would be a refinement and not a blocker.

[heyams]

@joaopgrassi i don't have permission to dismiss your "request for change". Your comment no longer applied.
please review it again and unblock this PR.