[Openid-specs-ipsie] IPSIE WG meeting minutes - June 24, 2025
Dean H. Saxe
dean at thesax.es
Sat Jun 28 19:48:36 UTC 2025
IPSIE WG members,
Below please find the notes from the June 24, 2025 meeting. They are also
available on GitHub
<https://github.com/openid/ipsie/wiki/2025%E2%80%9006%E2%80%9024> (possibly
with better formatting!).
-dhs
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
-
Welcome and antitrust policy reminder https://openid.net/policies/
-
OpenID Contributor Agreement reminder
https://openid.net/intellectual-property
-
Reminder about OpenID Slack
-
invite link:
https://join.slack.com/t/oidf/shared_invite/zt-30zg9louv-3HgJEwIL7vB3uWv2KEbLtw
-
Community Events
-
IETF 123, July 19 - 25 in Madrid, Spain
-
Authenticate, October 13 - 15 in Carlsbad, CA
-
IIW XVI October 28 - 30 in Mountain View, CA
https://www.eventbrite.com/e/internet-identity-workshop-iiwxli-41-2025b-tickets-1393125719529?aff=oddtdtcreator
-
IETF 124, November 1 - 7 in Montreal, Canada
-
Review profiles & issues
<https://github.com/openid/ipsie/issues?q=state%3Aopen%20label%3A%22agenda%22>
-
Check in with Dick about Connect WG status
-
https://github.com/dickhardt/enterprise-extensions
-
Clarification on intention of SL1 profile
-
https://github.com/openid/ipsie-openid-sl1/pull/3
-
Side car doc for common requirements
-
Proposed document published by Dean
https://deansaxe.github.io/draft-saxe-ipsie-common-requirements-profile/draft-saxe-ipsie-common-requirements-profile.html
-
Addresses a number of the outstanding FAL2 issues that we've
discussed over the past few weeks
-
Pulls common guidance (e.g. TLS, DNSSec) into a common profile
that is used across all other IPSIE profiles
-
Looking for feedback on initial draft, if feedback is generally
positive, we will call to adopt this draft
-
If adopted, common guidance will be removed from the OIDC SL1
draft
-
FAL2 Issues https://github.com/openid/ipsie/issues?q=is%3Aissue
state%3Aopen label%3Aagenda label%3AFAL2
<https://github.com/openid/ipsie/issues?q=is%3Aissue%20state%3Aopen%20label%3Aagenda%20label%3AFAL2>
-
Account Resolution https://github.com/openid/ipsie/issues/79
-
No feedback since last week
-
JIT Provisioning
-
No feedback since last week
-
auth_time, max_age, and prompt
-
https://github.com/openid/ipsie/issues/89
-
https://github.com/openid/ipsie/issues/90
-
https://github.com/openid/ipsie/issues/91
-
https://github.com/openid/ipsie/issues/92
-
https://github.com/openid/ipsie-openid-sl1/pull/4
-
RP Initiated federation https://github.com/openid/ipsie/issues/94
-
Subject Identifier Global Uniqueness
https://github.com/openid/ipsie/issues/93
-
Assertion presentation through a proxy -
https://github.com/openid/ipsie/issues/95
-
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 DickClarify 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20250628/9045ea87/attachment-0001.htm>
More information about the Openid-specs-ipsie
mailing list