HCL Domino Ideas Portal
Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
Thank you for the thorough breakdown—you are completely right about OIDC Core Section 12.2. A refresh token absolutely cannot be used to alter the sub claim or swap identity contexts.
To answer your questions on how this would work:
UX & UI: Yes, we use a drop-down in our web application where a user can select a different UPN from a list of accounts they own. These UPN values are populated in the client application via an initial configuration profile or an internal backend data source.
Authentication Trigger: When the user selects a different UPN, the application would indeed hit the Domino HTTP server's initiate_login_uri endpoint. We would pass the login_hint containing the desired UPN. The OIDC Provider would then evaluate that login_hint during the authorization request to bypass account discovery and boot a fresh authentication session for that specific identity.
Because of the OIDC limitations you mentioned regarding token refreshing, we will treat a UPN switch as a brand-new authorization lifecycle (firing a full auth code flow interaction) rather than attempting any token manipulation.
Our Real-World Context:
Our work environment has implemented Microsoft Power Pages and Dynamics 365 integrated with Azure AD B2C exactly this way. A custom backend API handles the token refresh mechanics, allowing users to leverage a web interface to change their organization (contact UPN) seamlessly after signing in with their single Digital ID email address.
For Domino to participate in this ecosystem today, switching from Dynamics Org A to Org B requires a complete, disruptive sign-out of Org A and a completely new sign-in for Org B to grab the new ID token UPN. We want Domino to be able to accept that fresh login_hint flow and step into the new identity context smoothly.
How exactly do you envision this working? Would your web application have a button or drop-down that end users could select that allowed them to pick a different UPN? How would those UPN values be populated in the first place? Would your application hit the Domino HTTP server's initiate_login_uri endpoint with a login_hint parameter showing the desired UPN, and your OIDC Provider would then DTRT upon receiving that login_hint in an authorization request?
I also don't see how you expect to use a refresh token to receive an id token for a different identity - that is prohibited by OIDC.Core section 12.2 which states that if an OIDC Provider returns an id_token (it might not - refresh tokens are normally used to replace expired access tokens) then the sub Claim MUST be the same as in the original id token. If you're talking about using an RFC 8693 OAuth 2.0 Token Exchange, then please note that would only return an access token, not a new id token -- the OAuth 2.0 "helper specs" like that one generally don't impact OIDC, which is a great thing, because then OIDC interoperability would be just as terrible as OAuth 2.0 interoperability.
If you do want to use the OAuth Token Exchange flow to obtain access tokens for a different identity that is owned by the same end user, then you'll want to implement that OAuth client functionality in your client application, and configure the Domino HTTP server for HTTP bearerAuth instead of Web Login with OIDC.
Related HCL support case is CS1423423