[Openid-specs-ipsie] Meeting minutes for 2025-06-17
Aaron Parecki
aaron.parecki at okta.com
Thu Jun 19 01:06:40 UTC 2025
Thanks for the productive discussion. Below are the minutes from the
meeting yesterday.
Please also share your thoughts on the mailing list or github threads for
the topics identified during the call.
# IPSIE WG Meeting Minutes
Date: 2025-06-17
## Attendees
* Aaron Parecki (Okta)
* Dean H. Saxe (self)
* Sean Miller (RSA)
* Kenn Chong (RSA)
* Qinglan Gao (RSA)
* Dick Hardt (Hellō)
* Karl McGuinness (Self)
* Nick Watson (Google)
* Jon Bartlett (Zscaler)
* Travis Tripp (HPE)
* Alex Chalmers (Self)
* Jeff Bounds (SailPoint)
* Vatsal Gupta (Self)
* Bjorn Hjelm (Yubico)
* Ameya Hanamsagar (Meta)
## Agenda
- Welcome and antitrust policy reminder https://openid.net/antitrust
- 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 in Madrid in July
- Authenticate October 13-15
- IIW October 28-30
https://www.eventbrite.com/e/internet-identity-workshop-iiwxli-41-2025b-tickets-1393125719529?aff=oddtdtcreator
- 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
- FAL2 Issues
https://github.com/openid/ipsie/issues?q=is%3Aissue%20state%3Aopen%20label%3Aagenda%20label%3AFAL2
- [Max authentication age](https://github.com/openid/ipsie/issues/90
)
- Recommend adding `max_age` claim to the RP request to the OP
in the OIDC profile
- [Auth Time claims](https://github.com/openid/ipsie/issues/89)
- Recommend adding the `auth_time` claim to the id token
- [Attribute Bundles/VCs](https://github.com/openid/ipsie/issues/84)
- Out of scope, recommend closing if there are no other comments
- [Authentication & Attribute Disclosure](
https://github.com/openid/ipsie/issues/77)
- Open for additional feedback
- We will include guidance in the side-car doc
- [Ephemeral Identities](https://github.com/openid/ipsie/issues/54)
- Re-raising this older issue since it appears in the NIST
SP800-63Crev4 guidance
- Looking for a volunteer to write guidance on ephemeral
identities to go into the side-car doc
- [Account Resolution](https://github.com/openid/ipsie/issues/79)
and [JIT Provisioning](https://github.com/openid/ipsie/issues/88)
- Looking for an author to write guidance on JIT provisioning.
May be the same author for Ephemeral Identities (#54) and Account
Resolution (#79) since all three concepts are interrelated.
Notetaker: Dean H. Saxe / Aaron
## Minutes
- Reminder about antitrust, participation agreement
- Reminder about IETF123 Madrid, IIW, Authenticate 2025
- Enterprise Extensions - check in with Dick
- Now published as an adoped draft
- Please chime in on the connect list with feedback
- Sean: Are these extensions standard or optional?
- Aaron: Draft defines claims/params needed by IPSIE
- Need a PR to change `session_lifetime` to `session_expiry` in the
OIDC SL1 draft to match the extensions draft
- TODO: Dean to file an issue and make the change.
- Travis: Tenant claim? Is this used in IPSIE?
- Aaron / Dick: This claim comes from OpenID Provider Commands and is
not in IPSIE currently.
- Aaron: The extensions spec is defining a group of things that are
needed by other profiles. We may not use all of the items defined in this
spec in IPSIE
- Travis: We use other claims to indicate tenancy
- Aaron: Unclear if we'll use this in IPSIE
- Dick: Happy to discuss further with Travis to drive consistency and
interop
- Aaron: EAP ACR values work has been published. Should the EAP group stay
active to address additional context classes?
- Travis: Is this related to the discussion last week?
- Aaron: Yes, we could do this in IPSIE or EAP?
- Bjorn: EAP is its own group.
- Dean: SHould we coordinate with EAP to figure this out?
- TODO: Aaron to check in with EAP chairs.
- Nick: (in chat) " is there any standard way to represent "infinite" for a
duration or timestamp? The only thing I've seen is omitting the field,
which could also be conflated with simple lack of support for the feature."
- Effectively creating an infinitely long session
- Nick: thinking about this in terms of RTs (which are out of scope in
SL1)
- Nick is asking re: any timestamp value, not specific to
`session_expiry`
- Aaron: Can see use cases for this, esp. if the OP can terminate a
session with a command (e.g. SL2)
- Dean: Can you set an arbitrarily far in the future time stamp?
- Nick: Possibly... may meet the same need
- Dean: Bring this to the AB Connect group/mailing list
- Nick: potential to use the ISO timestamp spec?
- Dick: Can we follow the cookie example, setting a time far into the
future. Special values require a larger code base to handle these values,
vs. checking a timestamp that expires in a hour, a day, a year, a decade...
- Nick to follow up on the AB list
### FAL2 Issues
- Issue 90: max authentication age
- Dean: RP needs to indicate max age to the IdP
- Dean: submitted a PR https://github.com/openid/ipsie-openid-sl1/pull/4
- Nick: this is very time-based vs risk-based authentication. Some RPs
will need an exact time, but what about risk-based?
- Dean: Agree we should be talking about longer term risk based. The
requirement from FAL2 is to specify max allowable age. But the RP could set
the max age to 10 years, but we need to specify max value.
- Dick: This is from the RP, why is that needed? Wouldn't this be a
policy at the IdP?
- Dean: FAL2 says RP SHALL specify max age to the IdP. It could be
agreed to by the parties out of band. The IdP also needs to return an
auth_time claim to the RP. Both are required at FAL2.
- Dick: Why the limit of the length of the nonce?
- Dean: That was already in the doc from FAPI
- Aaron: This requirement is that RPs send max age parameter, not that
IdPs must accept it.
- Dean: Correct. The OP then must respond with an auth time claim.
- Aaron: I'm on board with IdP being required to process max age
parameter, and required to send auth time, but less excited about requiring
the RP to send the parameter.
- Alex: Enterprises generally control the IdP in this flow. What is the
value for the enterprise in having the RP ask the IdP for max age?
- Travis: Within each tenant in HP Greenlake, we have different
policies the admin can set. Some customers want to manage things centrally,
but some only care about lifecycle management, but don't like to manage the
authorization level things centrally, would rather manage in the
application.
- Alex: I haven't run into that use case, but if it's useful that's
fine, just making sure we're aligned. As much as I like the NIST document,
the target audience isn't necessarily enterprise.
- Karl: Common with shared responsibility, the service provider may
want to protect itself indepentent of what the IDP configures. The SP has
brand risk. May not trust customers to configure good policies in the IDP,
may still want to add additional protections. Max age gives them the
ability to own that requirement.
- Dean: Max age is optional, but if specified it doesn't mean the IDP
_can't_ reauth.
- Dean: TODO follow up on mailing list about #89 and #90
- Issue #84 https://github.com/openid/ipsie/issues/84
- A couple weeks ago we determined this is out of scope, can we close
this?
- Kenn: Agreed
- Dean: No further feedback, will close
- Issue #77 https://github.com/openid/ipsie/issues/77
- Dean: A lot of this came back to trust agreements, I think we can
drop this. Will leave this open until next week.
- TODO: Dean to send this to the mailing list before closing next week
assuming no further discussion
- Issue #54 https://github.com/openid/ipsie/issues/54
- Dean: In Feb we discussed ephemeral identities. This is covered in
800-63. We have yet to handle JIT provisioning and binding those to an
identity. Looking for help from someone who has hands on experience with
JIT provisioning and capturing those and bringing them under management
- Travis: This is under active discussion internally
- Karl: Very few systems I've seen support true ephemeral identities.
I'm curious what's driving the requirement for true ephemeral, vs treating
this as JIT then handling it with provisioning later. Is this more workload
identity?
- Travis: Ephemeral may be a bad term for it. Incorrect example: with
AWS you can do role assumptions, then create a session...
- Karl: When you use organizations with SCIM you can't do that. There's
an STS model. The other use case would be session creation within the RP.
- Travis: We have a lot of large managed service providers. They send
in identities today via SAML and we JIT them. The MSP refuses to give us
the actual end user identity. We create these identities, then there isn't
really a lifecycle associated with them, we don't know if they should be
expired at the end. How do we mark that this should be deprovisioned at the
end of the session. It comes in creating a user account but at the end of
the session the user should be deactivated.
- Karl: I would expect this to be deployment specific. If you want to
put a trigger on session termination that's possible. The OP can signal
signal session creation and deletion.
- Aaron: If the hooks for JIT creation and account termination are in
place, isn't that enough?
- Travis: Today they could combine things like SCIM, but I still want a
signal that at the end of the session the RP should deactivate the identity.
- Dean: Wondering if we should defer working on ephemeral identities
- Travis: I'm fine with that. If you aren't aware of an existing way to
do that with a claim that's out there it makes sense to defer.
- Dean: TODO send an email to the list about this
- Dean: Agree with Karl that we should explore the possibility of
defining new things in AB Connect
- Dean: TODO send an email to the list about #79 account resolution to
get the discussion going ahead of next week's call
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20250618/db935788/attachment-0001.htm>
More information about the Openid-specs-ipsie
mailing list