[Openid-specs-authzen] OpenID Connect Email Account Linking Extension
Lombardo, Jeff
jeffsec at amazon.com
Wed Sep 24 18:06:03 UTC 2025
Hi Salim,
+1 to the comments made below:
- this sounds like an identity problem, so an OpenID Connect problem
- the point is you have been sent to the AuthZEN working group of the OpenID Foundation, not the OpenID Connect Working Group of the OpenID Foundation
This being said, and my personal opinion leaving the members of the OpenID Connect Working Group to give a formal answer, account linking is something that we do at AWS in Amazon Cognito<https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-identity-federation-consolidate-users.html>. Okta/Auth0 does the same<https://help.okta.com/wf/en-us/content/topics/workflows/connector-reference/auth0/actions/linkaccount.htm>. But this is outside OpenID Connect.
What happens is that:
* The user authenticates with one account for the Client Application
* The Client Application offers Account linking capabilities if the user wants to go there
* The user can decide to use the capability and the application will use the Access Token it has to call the Account Linking API
* The Account Linking API will authenticate the user through secondary accounts
* Any new minted token will bear the linked account information if successful starting from the next issuance
From your proposal you want to start the flow of linking at the Authorization request:
* The Linking flow as proposed will be initiated by the Client Application… but the client application has no clue:
* If there are some account(s) to link as the user is not even authenticated
* Which account(s) should be linked as there might be some false positive expectations: it is not because there is a jdoe at gmail.com<mailto:jdoe at gmail.com> that this is a account to be linked to john.doe at gmail.com<mailto:john.doe at gmail.com> while on the contrary mustangrider at gmail.com<mailto:mustangrider at gmail.com> might be another persona of jdoe at gmail.com<mailto:jdoe at gmail.com>. There are also privacy concerns on trying to reconciliate or propose association of accounts while the owner wants to ensure those remain disjointed.
Overall, this sounds like setting linking=true would add a lot of friction to the flow to go through while it is not or no longer necessary.
* I quite not get the linking period too… while would a linking expire after some time?
Overall, while thought experiment and gut feeling are great, OpenID Foundation and IETF work from problems from the field. If you want to pursue those proposal, you need to be able to answer to the broader question on why this has a better sense to deal with at the OpenID / OAuth layer than at the IdP layer.
Jeff
Jean-François “Jeff” Lombardo | Amazon Web Services
Architecte Principal de Solutions, Spécialiste de Sécurité
Principal Solution Architect, Security Specialist
Montréal, Canada
( +1 514 778 5565
Commentaires à propos de notre échange? Exprimez-vous ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.
Thoughts on our interaction? Provide feedback here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.
From: Openid-specs-authzen <openid-specs-authzen-bounces at lists.openid.net> On Behalf Of Eve Maler via Openid-specs-authzen
Sent: September 24, 2025 12:55 PM
To: AuthZEN Working Group List <openid-specs-authzen at lists.openid.net>
Cc: Eve Maler <eve at vennfactory.com>
Subject: RE: [EXT] [Openid-specs-authzen] OpenID Connect Email Account Linking Extension
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque.
I’m probably not helping by responding in this thread, since a proper discussion probably wants to live elsewhere, but here goes…
Usually either such multi-email associations are made heuristically based on common properties (as noted by Alex — see "identity resolution" systems as used by marketing), or are made deterministically by asking the user — as a one-time/extraordinary action — to identify and confirm a single related email at a time, through a traditional OAuth/OIDC linkage.
[cid:image001.png at 01DC2D5B.A93A0CE0]
Eve Maler, president and founder
Cell and Signal +1 (425) 345-6756<tel:+1-425-345-6756>
On Sep 24, 2025, at 11:19 AM, Omri Gazitt via Openid-specs-authzen <openid-specs-authzen at lists.openid.net> wrote:
Perhaps the OAuth WG redirected you to the OpenID Connect working group?
This has more to do with authentication than authorization.
On Wed, Sep 24, 2025 at 12:59 AM Salim BOU ARAM via Openid-specs-authzen <openid-specs-authzen at lists.openid.net<mailto:openid-specs-authzen at lists.openid.net>> wrote:
Hi Alex,
Thanks for clarifying. There isn’t a particular production use case I’ve seen; this draft is more of a thought experiment.
The idea came from observing how people sometimes end up with multiple accounts from the same IdP and wondering if there might be a standardized way to let them unify access under one primary identity.
I appreciate your perspective on whether this kind of functionality would be useful in practice, and I agree that concrete use cases will be important to validate or discard the idea.
Best regards,
Salim
On Wed, 24 Sept 2025, 08:18 Alex Babeanu, <alex.babeanu at indykite.com<mailto:alex.babeanu at indykite.com>> wrote:
Hi Salim,
- the OAuth WG directed you here? Interesting... I guess the angle would be that the `subject` in an AuthZEN request would be multi-valued... I think we already cover that through "boxcarring" in the AuthZEN spec.
- As for: " I could use example at gmail.com<mailto:example at gmail.com> as my primary identity and link example1 at gmail.com<mailto:example1 at gmail.com> to access the same app account." - I got that, and was indeed questioning whether this would actually ever happen in the wild. Did you write this draft based on an actual use-case you've seen? Others may have some input here too...
Cheers,
./\.
On Wed, Sep 24, 2025 at 9:07 AM Salim BOU ARAM <bouaram.salim at gmail.com<mailto:bouaram.salim at gmail.com>> wrote:
Hi Alex,
Thank you very much for taking the time to read the draft and share your feedback.
The OAuth WG suggested I discuss the draft here.
Just to clarify the “1-N secondary accounts” point: the idea is not that users must link multiple N accounts, but that they can choose to link additional accounts to their primary authenticated identity (up to an IdP-defined N limit). For example, if an app offers “Sign in with Google,” I could use example at gmail.com<mailto:example at gmail.com> as my primary identity and link example1 at gmail.com<mailto:example1 at gmail.com> to access the same app account.
This may not have been clear in the draft.
Thanks again for the feedback, and I look forward to more input.
Best regards,
Salim
On Wed, 24 Sept 2025, 07:54 Alex Babeanu, <alex.babeanu at indykite.com<mailto:alex.babeanu at indykite.com>> wrote:
Hi Salim-Amine,
Well, I'm not sure the AuthZEN group is the right group for this one, it looks more like an idea for the OAuth WG within IETF... I will let others weigh-in on that point.
About the proposal, I think I'm not clear specifically on this: " User authenticates 1-N secondary accounts (IdP-defined limit)"
--> based on experience in the field, users never actually do that. As a user, I know I wouldn't do it myself. I think there's more value for an organization in matching its various accounts based on common properties, than enabling a sort of "email/Account-SSO": after all, these users register different accounts for a reason: maybe for different types of access or even anonymity...
My humble $0.02...
Regards,
./\.
On Tue, Sep 23, 2025 at 11:28 PM Salim BOU ARAM via Openid-specs-authzen <openid-specs-authzen at lists.openid.net<mailto:openid-specs-authzen at lists.openid.net>> wrote:
Hello,
I’ve submitted a draft that proposes a way for an RP to let a user link multiple email accounts from the same IdP under a single primary identity. Secondary logins resolve to the primary account, and linkages can expire or be removed.
(https://www.ietf.org/archive/id/draft-bouaram-oidc-email-linking-extension-00.html)
I’m interested to know if anyone finds this idea useful.
This version is an initial draft and could be further enhanced based on community feedback.
Best regards,
Salim-Amine Bou Aram
--
Openid-specs-authzen mailing list
Openid-specs-authzen at lists.openid.net<mailto:Openid-specs-authzen at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-authzen
--
[Image removed by sender.]
Alex Babeanu
Lead Product Manager, AI Control Suite
t. +1 604 728 8130
e. alex.babeanu at indykite.com<mailto:alex.babeanu at indykite.com>
w. www.indykite.com<http://www.indykite.com/>
--
[Image removed by sender.]
Alex Babeanu
Lead Product Manager, AI Control Suite
t. +1 604 728 8130
e. alex.babeanu at indykite.com<mailto:alex.babeanu at indykite.com>
w. www.indykite.com<http://www.indykite.com/>
--
Openid-specs-authzen mailing list
Openid-specs-authzen at lists.openid.net<mailto:Openid-specs-authzen at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-authzen
--
Openid-specs-authzen mailing list
Openid-specs-authzen at lists.openid.net
https://lists.openid.net/mailman/listinfo/openid-specs-authzen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20250924/9fafd57e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD0000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: ~WRD0000.jpg
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20250924/9fafd57e/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16340 bytes
Desc: image001.png
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20250924/9fafd57e/attachment-0001.png>
More information about the Openid-specs-authzen
mailing list