Skip to content

2025‐08‐19

Jump to bottom
Aaron Parecki edited this page Aug 20, 2025 · 2 revisions

IPSIE WG Meeting Minutes

Date: 2025-08-19

Attendees

  • Aaron Parecki (Okta)
  • Shannon Roddy (self)
  • Karl McGuinness (self)
  • Kenn Chong (RSA)
  • Jen Schreiber (Workday)
  • Jeff Bounds (SailPoint)
  • Dean H. Saxe (self)
  • George Fletcher (Practical Identity LLC)
  • Alex B Chalmers (self)
  • Dick Hardt (Hellō)

Agenda

Notetaker: Dean H. Saxe and Aaron Parecki

Minutes

  • Note interop date is January 22, 2026, not January 29 as previously announced.
  • Common requirements - we will review open PRs today
  • SCIM IL1 call for adoption - https://github.com/openid/ipsie/pull/72
    • Jeff Bounds - gave it a review, no issues observed
    • To do:
      • Merge PR to indicate call for adoption
      • Call for adoption email by Aaron
      • If successful, create a repo for this doc and move doc to repo
  • Open PRs
    • openid/ipsie
      • #107 - Not allowing IdP-initiated at SL1 would block SAML at SL1 entirely. This PR moves preventing IdP-initiated to SL2.
      • Kenn: Would there be a way in SL3 to describe how to do it securely?
      • Dean: The requirements in SL2 would also apply in SL3. SL1 doesn't make a statement about IdP-initiated federations. We can get to this when we write the SAML SL1 doc.
      • Dean: Will merge after the call
      • #106 - remove reference to draft 800-63 version.
      • George: the comment also references draft 4. Can we make this consistent "800-63-4" instead of "rev4"
      • Dean: Fixed. Will merge after the call.
      • #57 - changes MFA to phishing resistance at SL1, a PR from march.
      • Dean: Would love folks to provide feedback on this change.
      • Dean: Chair hat off, trying to enforce phishing resistance at SL1 could be problematic for people adopting
      • Shannon: The consensus in another working group for how to accomplish phishing resistance is passkeys or x509, and there are places where those are hard to deploy, so this would make it hard to adopt.
      • Kenn: Agreed, this is too high of a bar.
      • Karl: What's the versioning story? Could we revise SL1 to add phishing resistance in 2 years?
      • Aaron: Other OpenID specs have published updated versions, shouldn't be a problem
      • Alex: There will always be some situations where phishing resistance isn't important to the business case. So for SL1, MFA is the bar.
      • Dean: There are a lot of orgs that deploy VDI, phishing resistant mechanisms might not work in virtualized machines.
      • George: I'm also worried about MFA, I don't think we actually mean multi factor, a lot of times factors you know are actually something you have. If we want to remove phishing resistant requirement, we need to actually say "a second mechanism", but I don't know if "factor" helps clarity. Then does risk count as a factor? What else counts? How do you evaluate whether this meets the appropriate level of security? I don't know what value we get with saying "MUST do mfa".
      • Dean: We had some language about risk assessment about not updating the auth_time claim
      • Aaron: enforcing MFA isn't actually an interop concern
      • George: We did want IPSIE to represent leveling up security. We don't have a good way to force the IdP to do something.
      • Dick: My recollection with SL1 is the application could ask for a certain authentication, the IdP must communicate it back.
      • Dean: That is in SL2.
      • Dick: I was working with the github API, they made up their own claim. SOC2 compliance says everything has to be 2 factor. So there is work we could do to help standardize.
      • Dick: OpenID convention for versioning ends with _1-0.
      • Dean: Pam and I had started working on something around MFA/2FA
      • Karl: The IdP needs to support a minimum set of acrs that the RP can request. There's a gap around the AAL2 scenarios. We were going to create an IPSIE ACR context. We should take the common scenarios today and make ACR values, with versioning. The SL1 question is then what ACR values to support.
      • Dean: There is an open issue https://github.com/openid/ipsie/issues/86 to talk about this but we haven't gotten back to it. Is this something we should define for the interop event?
      • Kenn: Maybe it would be easier to say you have to do something better than simple passwords for SL1
      • Dean: It sounds like as written, we won't accept #57. Would love more comments before we make any decisions.
      • Karl: This seems like something we want to get broader feedback on how strict we want to be.
      • TODO: reach out and get external feedback
      • Aaron: Sounds like we shouldn't rush in to this for the interop event
      • Karl: Document the default policies from major IdPs today
      • #14: can close without merging the PR
    • openid/ipsie-common-requirements-profile
      • #5: remove restriction on IdP initiated federation
      • Dean: removed the two sentences restricting IdP-initiated federation. Will merge after the call.
      • #3: updated the date of 800-63-4
      • Aaron: should we also make this consistent with "800-63-4"
      • Dean: Done
    • openid/ipsie-openid-sl1
      • #11: removed reference to refresh tokens
      • Dean: Refresh tokens are optional since we only reference the userinfo endpoint. Any concerns with removing this line?
      • George: The reason this came up was with session management. We moved some of those to SL2, so that's why this can be removed?
      • Karl: Should the IdP always support the option of getting a refresh token for IdP renewals? Or is that something the IdP can choose? I didn't think that part was clear yet. I thought we didn't need to secure refresh tokens for getting access tokens. But I thought offering the option for refresh tokens in SL1 was still useful. We still may need requirements around refresh tokens, but only in the context of offline access ID tokens. Having language like IdPs must support offline access would be beneficial.
      • Dean: It looks like we don't have a PR for issue #74 "refresh tokens vs full page redirects"
      • #9: anchor auth_time claim to last interactive user authentication
      • Dean: This is the PR I was trying to reference before, not allowing risk assessment as a factor that updates auth_time.
      • Kenn: Looks good to me.
      • George: We had the conversation about having a separate time for when the session was checked. We are keeping track of session validity time and user authentication time. Is there value in the RP knowing we validated the user session through a risk based method, but no interactive authentication was done.
      • Dean: This language does that, but not a timestamp. Do we need an array of auth_time claims, we decided that was too complex, this is the middle ground.
      • George: If there is already amr:mfa+rba, the RP doesn't know what the IdP did for future risk-based checks.
      • Dick: I'm thinking we should keep it simple now and get feedback from the market before making it more complex.
      • Karl: I think there's value in clarifying the use of rba. It's linked to the issuance of the ID token, not about the whole session. Use auth_time to determine the last time the user was interactive.
      • George: We may make requirements in IPSIE that prohibit large providers from complying. When we implemented max_age in OpenID 2 and connect, there was a very large social provider that said I don't care what you send me, if I don't need to authenticate the user I'll send the user back anyway. The IdP would send back amr=rba in that case? Then it's up to the RP to decide to continue in that context. The IdP says i'm not going to challenge the user, so what do we say has to be returned.
    • Dean: We are at time for today.
Clone this wiki locally