[Openid-specs-ipsie] 2025-07-08 meeting minutes
Aaron Parecki
aaron.parecki at okta.com
Wed Jul 9 18:18:50 UTC 2025
Hi all, below are the minutes from the July 8th meeting.
# IPSIE WG Meeting Minutes
Date: 2025-07-08
## Attendees
* Dean H. Saxe (self)
* Aaron Parecki (Okta)
* Sean Miller (RSA)
* Kenn Chong (RSA)
* Shannon Roddy (self/LBL)
* Alex B Chalmers (self)
* Mark Maguire (Aujas Cybersecurity)
* Bertrand Carlier (Wavestone)
* George Fletcher (Practical Identity LLC)
* Jeff Bounds (SailPoint)
* Bjorn Hjelm (Yubico)
* Travis Tripp (HPE)
## 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
- Interop Event Planning
- Poll for dates: https://whenavailable.com/invite/bN6AdzU027LQPjeLQ4F7
- 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
- [OIDC SL1 Introduction](
https://github.com/openid/ipsie-openid-sl1/pull/3)
- Related [issue](https://github.com/openid/ipsie/issues/73)
- Review Dean's edits from last week's call. Do we have consensus
to merge this change to the introduction?
- 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
- Will start call for adoption after this call
- FAL2 Issues
https://github.com/openid/ipsie/issues?q=is%3Aissue%20state%3Aopen%20label%3Aagenda%20label%3AFAL2
- [Account Resolution](https://github.com/openid/ipsie/issues/79)
and [JIT Provisioning](https://github.com/openid/ipsie/issues/88)
- Update from Dick/Karl about this topic in AB/Connect
- `auth_time`, `max_age`, and `prompt`
- https://github.com/openid/ipsie/issues/89
- Need someone to take this on and define an extension to
represent auth_time x amr
- https://github.com/openid/ipsie/issues/90
- Review the [updated text](
https://github.com/openid/ipsie-openid-sl1/pull/4) and ask Aaron to merge
if we're at consensus.
- https://github.com/openid/ipsie/issues/92
- OIDC SL1 needs language on how to manage the `prompt`
parameter
- 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
- Should there be a separate issue to manage proxy chaining?
- AOB
Notetaker: Dean / Aaron
## Minutes
- Antitrust policy reminder & Contributor Agreement
- SL1 Profile interop
- working on a December date, Gartner does not have capacity for IPSIE
this year
- Poll for interop date options -
https://whenavailable.com/invite/bN6AdzU027LQPjeLQ4F7
- If these dates do not work for you for whatever reason, please
reach out to Aaron and Dean
- Okta to host in the SF office, half to full day event
- Will enable remote presentation
- Goal is to settle a date by the end of July.
- Aaron to email a summary of the discussion to the mailing list and
slack
- Dick was not in attendance, no WG status on the enterprise extensions
### OIDC SL1 intro
- Dean: PR #3 on SL1 profile, updates intro to clarify use of OIDC.
Discussed last week and made a couple further changes. Are we comfortable
with the changes now?
- Mark: "require" isn't necessarily as clear as "mandate"
- Alex: Similar concern. Maybe the last sentence about refresh token/dpop
is even required
- Dean: I want to be clear that refresh tokens are optional, maybe we need
to be clear about when they are optional.
- Alex: That might be better broken up into the body of the document rather
than the introduction
- Sean: I like keeping it in the intro but I like the idea of using the
word "optional" and fleshing out the use cases of when it would be used.
- Aaron: I think we can come up with a quick edit. "As a result... are
optional"
- Sean: :+1: and we can expand this in the body
- Mark: :+1:
- Dean: Aaron can merge when ready. Sean and Alex if you want to add more
clarifying text in the doc please do.
### Sidecar doc
- Dean: Sidecar doc for common requirements. I updated it based on feedback
so far. We would like to see whether this is at a point it can be adopted
by the working group. Doesn't mean it's perfect, but it's far enough along
to adopt and then collectively make updates to it. That will also allow us
to go to the SCIM/OIDC/SAML profiles and pull out all the common
requirements since they are captured here. Looking for questions/feedback
on this.
- Dean: Aaron are you comfortable starting a call for adoption?
- Aaron: Yes
### FAL2 issues
- Dean: FAL2 requires the IdP to issue an `auth_time` claim. It also
requires the ability for the RP to specify the requested auth time. For
OIDC, this has resulted in another issue about the `prompt` parameter,
which is equivalent to `auth_time=0`. This resulted in another issue that
the `auth_time` claim doesn't necessarily correspond to the amr claims. For
example auth_time=0 with phrh, at time +5 min we have a reauth based on
risk which doesn't require hardware. We then have multiple amr claims
(phrh, rba), so what does the auth_time claim refer to? What I'd like to do
is separate out the requirements for max_age and auth_time and prompt, then
separately come back to the multiple auth_time/amr claim question.
- Dean: PR #4 adds a few statements to the OIDC SL1 profile. "MUST contain
the auth_time claim". This doesn't address which event this refers to. Also
added a note that this is related to NIST FAL. Also adds that the OP "MUST
support max_age parameter" but not requiring the RP to send.
- Mark: Taking a step back, the value of IPSIE is when the CISO buys a new
SaaS app it will be compliant. So not making the RP validate max_age
undermines the value. Why not have the RP be required?
- Dean: I think that's backwards. max_age is RP request to the OP. What is
returned in the ID token is the auth_time claim. So the RP MAY send the
max_age claim "this is the longest time I want to allow".
- Mark: I think a burden on the RP would be more helpful. If I'm a CISO i'm
going to trust ping/entra/okta/etc. What I don't trust is the 1000 SaaS
apps I'm using. So if they are IPSIE SL1 I want to know they are doing the
validation.
- George: What I'm hearing is we shouldn't require the RP to send a
max_age, but if the RP does then they need to validate that the returned
auth_time is valid for the max_age they sent.
- Mark: At minimum I agree. But I would be ok requiring the RP to use
max_age.
- George: There's a bunch of UX implications of leveraging max_age. This
hits both the RP and OP. I could see requiring the RP to support the
capability of max_age, but you don't want the app to always send max_age,
you only want it in certain contexts.
- Dean: What I see is max_age being used by the RP saying to the IdP that I
only want to issue the ID token if the max_age is less than X. It's a risk
mitigation step for the RP.
- Aaron: I think it's the session_expiry claim that gets Mark the control
needed
- Mark: Good with me.
- Travis: The way you put it seems much easier for an RP to implement where
it delegates the policy enforcement to the OP. Will we have SL2 that is
more restrictive?
- Dean: I don't recall conversations that got this deep in SL2 about things
like the RP must send max_age.
- Dean: Do we think this PR #4 is sufficient to merge this?
- George: I'm good with this.
- Aaron: Will merge now
- Dean: Next: auth_time * amr mapping. We need an extension to the core
spec that allows mapping auth_times to amrs so we know what happened at
what time. A first attempt is in [this comment](
https://github.com/openid/ipsie-openid-sl1/pull/4#issuecomment-3029279185).
Does this make sense? Is there a better formatting? Who can carry this
forward to write this as an extension for the AB Connect group?
- George: Meta question. The initial ID token was auth_time=X and amr=phrh.
Then the RP requests max_age, and gets a new ID token and new auth_time.
Why not make the amr valid for only the auth_time in the ID token. What you
lose is the overall authentication context. But I'm not sure we even have a
way to request the full session context over the lifetime of the session.
That's a much bigger conceptual object than auth_time and amr.
- Dean: My concern is say I log in to the IDP at T0, I go to RP1 at T+5,
then at T+10 I go to RP2. Between initial login and T+10 a risk auth
happened. Would the ID token have only rba or would it have a claim that I
initially used a phrh and then did rba?
- George: The semantic object you're looking for is the session
authentication context history. OIDC has no concept of an authentication
context session history. I'm a bit worried about getting a little of that
by creating arrays of auth_time and amrs if there are other elements that
would be desired. It makes me wonder if we should go back to AB connect and
ask if we should have an extension that enables the RP to request a full
session context history which becomes a new object. Then auth_time and amr
would be specific to the most recent auth event.
- Dean: I don't think we're too far in how this should look.
- Bertrand: I have the same concern as George, are we trying to invent
something that should be done in AB Connect? I think we should have a
simple auth_time claim for compatibility. What should the order of the amrs
be?
- Dean: Yes we will not define this here, the intent is if we need this
kind of thing we would build the extension in the AB COnnect group. But
good point about having the auth_time claim for backwards compatibility.
- TODO: Dean to pull
https://github.com/openid/ipsie-openid-sl1/pull/4#issuecomment-3029279185
into a new issue
- TODO: Verify the ability/need for IdPs to add this to their products
@aaronpk. Make sure this is an actual, concrete issue that needs to be
solved
- George: If you think about auth requirements it's pretty critical for
making authorization requirements. If it's not in the ID token then how
does your PDP make a decision? Understaing the full authentication session
context history is pretty critical from a dynamic perspective.
- Dean: I agree, as we see more movement towards continuous authentication,
we'll need this data to be much more clear to make good decisions.
### prompt parameter
issue #92
- Dean: I'm not sure what to do with `prompt` in IPSIE to avoid having
multiple ways to request reauth.
- George: I agree that historically we treated `max_age=0` to be the same
as `prompt=login` but I'm wondering whether that is the right thing to do.
`prompt=login` should require that the user sees some challenge. The
question is whether the user MUST/MAY/SHOULD/MUST NOT see a challenge.
- Aaron: So you're saying we should specifically define the behavior of the
combination of max_age and prompt?
- George: Right, either we need to disallow prompt, or define the
behaviors. I know there are some people who would want to use `max_age=0`
with no `prompt` to mean if the IdP can silently update the authentication
status then that's ok. But there are also cases where the RP wants the user
to be prompted. We need to put out of scope "is this really George". We can
allow for a mechanism to require the user engage in the user interface some
way.
- Dean: George would you mind commeting on this issue or push a PR?
- George: Can you tag me in the issue?
- Dean: :+1:
### RP initiated federation
- Dean: At FAL2, RP-initiated federation is required, and IDP-initiated is
not allowed.
- Kenn: Can someone explain RP-initiated vs IDP
- Dean: It's the difference of where the transaction starts. Shannon can
you elaborate on the risks of IDP-initiated?
- Shannon: There's a good article about why you shouldn't do IDP-initiated.
I'll see if I can find the article.
- Alex: IDP-initiated is a holdover from SAML 1.1. The problem is you're
sending a SAML response out in the wild without being asked for an auth
request.
- Shannon: It's also known as "unsolicited". In other words the RP didn't
solicit a sign-in request so it has no way to know if it's valid.
- Aaron: Want to call out the UX experience that causes people to think
they need IDP-initiated, creating a portal at the IDP where you can click
an app to launch it. That is also possible with RP-initiated, it just
requires the IDP to tell the RP to start an auth request. Described in OIDC
as "Third party login"
https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin
- Shannon: There are still some SaaS apps that don't support RP-initiated
at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20250709/a856e28b/attachment-0001.htm>
More information about the Openid-specs-ipsie
mailing list