[Openid-specs-authzen] OpenID Connect Email Account Linking Extension

Salim BOU ARAM bouaram.salim at gmail.com
Wed Sep 24 18:21:16 UTC 2025 

Hi Jeff,

Thanks a lot for the detailed reply and for sharing how AWS handle this is
really helpful context.

Just to clarify, in my idea the flow still starts at the app side with a
normal OIDC login, but with an extra option for the user to link other
accounts. Each account (including the primary) is authenticated normally by
the IdP, so the IdP remains in control.

The main thought behind this draft is whether having a standardized way to
do this at the IdP level could make life easier for apps and provide a more
consistent user experience, instead of building custom linking APIs.

Best,

Salim





On Wed, 24 Sept 2025, 20:06 Lombardo, Jeff, <jeffsec at amazon.com> wrote:

> 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
>       that this is a account to be linked to john.doe at gmail.com while on
>       the contrary mustangrider at gmail.com might be another persona of
>       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.
>
>
>
>
>
> Eve Maler, president and founder
>
> Cell and Signal +1 (425) 345-6756 <+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> 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>
> 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 as my primary identity and link
> 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>
> 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 as my primary identity and link
> 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>
> 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> 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
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
>
>
>
> --
>
> [image: Image removed by sender.]
>
>
> * Alex Babeanu*
> Lead Product Manager, AI Control  Suite
> t. +1 604 728 8130
> e. alex.babeanu at indykite.com
> w. www.indykite.com
>
>
>
>
> --
>
> [image: Image removed by sender.]
>
>
> * Alex Babeanu*
> Lead Product Manager, AI Control  Suite
> t. +1 604 728 8130
> e. alex.babeanu at indykite.com
> w. www.indykite.com
>
> --
> Openid-specs-authzen mailing list
> 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/e1e2d629/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD0000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20250924/e1e2d629/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16340 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20250924/e1e2d629/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD0000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20250924/e1e2d629/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16340 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20250924/e1e2d629/attachment-0003.png>

More information about the Openid-specs-authzen mailing list