Skip to content

2025‐06‐24

Jump to bottom
Dean H. Saxe edited this page Jun 28, 2025 · 2 revisions

IPSIE WG Meeting Minutes

Date: 2025-06-24

Attendees

  • Dean H. Saxe (self)
  • Sean Miller (RSA)
  • Kenn Chong (RSA)
  • George Fletcher (Practical Identity LLC)
  • Dick Hardt (Hellō)
  • Anatoly Podstrelov (EDETEK)
  • Jon Bartlett (Zscaler)
  • Jeff Bounds (SailPoint)
  • Bjorn Hjelm (Yubico)
  • Shannon Roddy (self/lbl)
  • Jen Schreiber (Workday)

Agenda

Notetaker: Sean Miller

Minutes

  • Antitrust statement and contributor agreement reminder
  • Reviewed community events coming up - IETF (July 19), Authenticate (Oct 13-15), IETF (Nov 1-7)

Enterprise extensions update - nothing new from Dick

Clarify use of OIDC SL1 profile - updates to the introduction section, Dean asked for feedback as comments on the pull request and open discussion

  • George: suggested that we make it clear this is an extension of the general SL1 profile to be OIDC specific. Where did we land in regards to SL1 for SAML?
  • Dean: Yes, a separate profile
  • Sean: Do we need a link back to the general profile to make it clear this is the implementation of the profile leveraging OIDC
  • Dean: This document will clarify how federation is achieved for OIDC for SL1. May be helpful to go back to refresh the introduction from the notes so it is clear how this pieces together. Eventually this will be put into a larger OIDC document.
  • George: I just added a comment to the PR to the effect… “The IPSIE OpenID Connect SL1 Profile is an implementation of the IPSIE SL1 requirements for the OpenID Connect protocol. This specification is intended to meet the”
  • Dean: We will leave this open for a week and come back to it. Please review and add comments to the PR. Thanks George for adding the comment to the PR

Side car doc for common requirements - https://deansaxe.github.io/draft-saxe-ipsie-common-requirements-profile/draft-saxe-ipsie-common-requirements-profile.html

Dean: Wanted to capture common requirements like FAL2 in this doc. Pushed this yesterday. Please review and see if you agree with the direction of the document. Goal is to agree if we want to adopt this doc as part of our work and make it part of our deliverables for the SL1 interop later this year Dean: Looking for more discussion on the mailing list so we can discuss majority outside this meeting and just sync up. Will review next week with the goal to bring this in for adoption Dick: I tend to track the slack channel more than email Dean: I will try to cross post in the future George: Email is the official channel and slack loses messages after 90 days for the OpenID Foundation. Good to cross post Dean: FAL2 - Account Resolution is the first topic. No feedback on this idea of account resolution. You may have multiple identifiers for a particular subscriber. Not sure if we need to handle this in the SL1 profile George: Given IPSIE is both relying party and IDP related, you run into this problem as it is unclear where you created an account on signin the first time. This is one case where account resolution comes into the user experience. Dean: This might be where reality has a headon crash with our intentions. As a user I go to the foo app and sign up with my corporate account because we dont have a relationship with the service provider. Later I may come in and we have a relationship and I may want to tie my account to that or i might want to keep them separate. Reality is a lot of enterprises may evolve where we need to unwind a mess between onboarding and account evolution. George: From IPSIE, accounts with the idp tenant must be distinct Dean: So if the enterprise later has a relationship with the relying party is that a distinct account? Now I may have two accounts and what controls are around the accounts (which does the employer control) George: If we allow account resolution, then we may have to require that relying parties allow some form of spin off of accounts. How do we disentangle that when you leave the company? If we move into an IPSIE environment and I am the enterprise controlling the environment, then I would like all the accounts to be clean and managed by me. Easier to manage and define clear boundaries. Still creates messiness Shannon: A lot of this is created by email accounts that arent managed Dick: This is going to be challenging for us to say how this should work as part of IPSIE. There are may different ways this may work. What happens to accounts when you change to managed accounts will really vary. We may want to right some guidance but not necessarily how it must work. Shannon: This is also a problem with email as a discovery Anatoly: From the enterprise perspective, email equals account. You either need to block at onboarding or cleanup when things switch over from personal accounts. Dean: So IL1 local create can still stand if you have a relationship with the application (RP). Where we need to write some guidance is probably in the overarching set of requirements where the email address associated with the user is now a customer, there needs to be a transition pathway. The pathway we cant define. Every RP will need to define that pathway and it may be nothing. Using my amazon.com account I create an account at foo RP. Amazon purchases access to the foo app. There then needs to be some process defined by the enterprise at that point. Dick: The enterprise may need to express some policy then that is black and white. If your account doesnt meet x, they will be blocked. Anatoly: Exactly, that is what we see where the non-compliant accounts are blocked/deleted since they dont meet the enterprise policy Shannon: This gets into the account linking issue. If I am participating in this working group but then move to another employer, do my efforts for this working group not follow me to the new employer? Dean: Glad you brought this up Shannon: Happens all the time with academia. So it is reallying both a relying party and an enterprise decision. This is part of the problem since email addresses are actual accounts Dean: Right, they are used as identifiers to accounts. Should the approach then be that the app must support some manner of being able to move the account under enterprise control but it is a decision between the RP and enterprise how/if that occurs. So we define what must be supported but not how George: We might be able to use some of the tenant work Dick is doing to cover this. Enterprise accounts must be part of the enterprise tenant, and those accounts at the relying party are distinct. If account resolution is required, the decision how that is done is out of scope of IPSIE Shannon: This isnt just an enterprise issue. If I want to move from Apple to Google, the same issue exists. Dean: Will go away and try to frame this up with words on the page. There is no universal solution here George: Most implementations do not support login alias/identifier to be changed. Not sure if in IPSIE if we want to require that the alias/identifier can be changed. The semantics for how the alias/identifier is used will really vary Shannon: Already in SAML federations we are already trying to separate email address from subject identifier but implementations are still using them for both George: So do we need to pull them into scope or leave them out and highlight them as things to think about or we are going to have to be concrete on what capabilities are required Shannon: Problem is we may have users like interns/contractors that need to authenticate Dick: I dont think we can specify it. It is very RP and enterprise specific. Anatoly: I just dropped a bunch of ideas at the bottom of the notes (Some Ideas) Shannon: I would agree with trying to encourage RPs to not use email address as the unique identifier but it will be hard to prescribe it for all. Dean: I will go back to the notes and see if I can write some draft language

ID Tokens issues by OpenID Providers

  • must support max_age parameter, if greater than the OP must reauthenticate the user George: the RP can send a max_age of 0, what is experience for the IDP then? Login everytime could be a bad user experience and might be giving too much power to the RP in driving the user experience. Dean: What was the discussion around the prompt parameter? George: It was something google might look at but it decides if it makes sense to prompt or not Dick: An authentication does not mean the user had to do something. It may be some type of re-evalaution of our confidence in the authenticated user. Sometime for compliance, the RP may need to enough certainty that after some time you are idle then you may have to login again. Amazon might allow you to add to the cart but at checkout evaluate the age of the authentication and re-auth. George: Right, it is more like we need to evaluate the confidence and authenticate if we are under the confidence. We need to add some context what we expect for the auth_time and what will the IDP do with it. IDP does a check but is it considered an auth? Shannon: SAML hat on I would look at force authn Dean: Thanks for raising this. Hadnt thought of this way but we may need to think more about what re-authentication means for IPSIE. I would encourage people to discuss and this may be more difficult than initially thought.

-- Some Ideas -- are these AI generated??

Here's a comprehensive outline of the key use cases to consider when designing an identity service with the explicit separation of application accounts from user email addresses, allowing the email to change independently:

1. User Onboarding

  • Initial Account Creation:

    • User signs up with an initial email (could be work or personal).
    • Identity system assigns a unique, persistent user ID.
    • Email address is verified as a contact method but not as the primary account identifier.

  • Alternative Registration Method:

    • Users may register without an email initially, using phone, external IDP, or other identifiers.
    • Email is added later as a communication channel, rather than primary account identifier.

2. Email Address Change

  • User-Initiated Email Change:

    • User changes their email due to job change, provider switch, etc.
    • Identity system validates and confirms new email address through a verification link.
    • Historical association between emails and account is retained for audit/compliance purposes.

  • Admin-Initiated Email Change:

    • Administrator updates user email, e.g., corporate domain migration.
    • User receives notification at both old and new emails, confirming change.
    • All subsequent notifications and communications sent to the new verified email.

3. Authentication and Recovery

  • Login Using Alternative Identifiers:

    • Users authenticate primarily using a username, unique ID, or a federation mechanism (e.g., OAuth, SAML).
    • Email address is never used as primary login, minimizing disruption if email changes.

  • Recovery of Access:

    • Multiple recovery methods available (secondary emails, mobile numbers, authenticator apps).
    • Email address changes trigger security review processes to avoid account compromise.

4. Offboarding (Email/Identity Removal)

  • User Departure (Employee Leaves Company):

    • Corporate email removed, but application account persists if allowed.
    • Transition user to a personal email or another suitable method (secondary contact).
    • Identity maintains account linkage to the unique user identifier, independent of email.

  • Permanent Account Closure:

    • User or admin initiates complete account termination.
    • All linked identities/emails archived or deleted based on policy.
    • Unique user identifier retired permanently.

5. Conflicting Emails

  • Email Already in Use by Another Account:

    • User attempts to change email to one already associated with a different account.

    • System detects conflict, prompting resolution:

      • Merge accounts (if applicable).
      • Deny request and prompt user to choose alternative email.
      • Offer resolution through administrator mediation or self-service verification workflows.

  • Duplicate Email during Onboarding:

    • System identifies that provided email is already associated with another account.

    • Prompt user for clarification:

      • Recovery flow for existing account.
      • Choice to create a secondary identity (rarely recommended).

6. Account Transfer

  • Transfer Ownership of Account (Corporate/Role Change):

    • User transfers ownership of their application account to another user (common in role-based systems).
    • Identity system manages permissions and transfers application context clearly to new account owner.
    • Historical audit trails of transfers maintained for compliance.

  • Transfer Between Personal and Professional Context:

    • Account initially created under professional (work) context transitions to personal use.
    • Identity system updates context attributes but maintains the same underlying unique identity.

7. Federated Identity Integration

  • Third-party IDP Integration (SSO):

    • User logs in via SSO; email from external identity provider might change.
    • Identity system ensures the unique user ID remains consistent despite external email attribute changes.

  • Email Change in Federated IDP:

    • External provider notifies identity service of email attribute changes.
    • Identity service verifies and updates the linked communication email seamlessly.

8. Auditing and Compliance

  • Historical Email Association:

    • Audit trail maintained showing all historical email addresses associated with the unique user identifier.
    • Ability to retrieve activity and identity validation details through historical identifiers.

  • Compliance and Data Privacy Management:

    • Emails separated from core identity allow precise handling of GDPR or other privacy requests (email anonymization without loss of account historical data).

9. Notification and Communication Management

  • Dynamic Notification Routing:

    • Notifications routed to current verified email(s).
    • Emails flagged invalid/unreachable trigger user verification or administrative alerting process.

  • Fallback Communication Channels:

    • Additional contact points (phone, secondary emails, push notifications) registered to avoid communication disruptions.

10. User Profile Management

  • Managing Primary and Secondary Emails:

    • Users maintain a primary communication email and multiple secondary email addresses.
    • Clearly defined preferences for different types of communications.

  • Visibility of Email Addresses to Others:

    • Control over email visibility settings within profile (public/private/limited visibility to admin).

This comprehensive scenario coverage ensures robust handling of identity/account continuity despite changes to email addresses and supports compliance, security, user convenience, and administrative clarity.

TODO:

  • Dean to review notes and write some draft language for the account resolution
  • Members to review PRs for FAL account resolution and max_age
Clone this wiki locally