2025‐06‐17 - openid/ipsie GitHub Wiki

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

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