2025‐05‐13 - openid/ipsie GitHub Wiki

IPSIE WG Meeting Minutes

Date: 2025-05-13

Attendees

  • Aaron Parecki (Okta)
  • Dean H. Saxe (Beyond Identity)
  • Kenn Chong (RSA)
  • Dave Bryant (RSA)
  • Sean Miller (RSA)
  • Mark Maguire (Aujas Cybersecurity)
  • Jon Bartlett (Zscaler)
  • Vatsal Gupta (Apple)
  • Filip Skokan (Okta)
  • Jeff Bounds (SailPoint)
  • George Fletcher (Practical Identity LLC)
  • Karl McGuinness (Self)
  • Bjorn Hjelm (Yubico)

Agenda

Notetaker: Dean H. Saxe and Aaron Parecki

Minutes

  • We will cancel the WG call during the Identiverse conference

Review profiles & issues

Check in with Dick about Connect WG status

  • https://github.com/dickhardt/enterprise-extensions
  • Dick is not on the call
  • This was added to the connect WG for consideration/adoption
  • adds claims to ID tokens and authn request params
  • IPSIE members should read and provide feedback
  • MikeJ: It was discussed yesterday on AB call
    • these are features that IPSIE wants/needs
    • Nothing is "new", we've discussed them before in AB
  • Dean: Next steps?
  • Mike: contribution evaluated for a couple of weeks, if there is favorable sentiment, they will do a call for adoption
  • Aaron: How can IPSIE members get involved/help support?
  • Mike: Read it, join the AB connect WG, send feedback (support/support with changes/not supported)

FAL2 Issues

FAL2 Attribute Bundles

  • https://github.com/openid/ipsie/issues/84
    • Dean: mostly about verifiable credentials, in particular VCs held in a wallet on a phone
    • Dean: we haven't talked about VCs at all in IPSIE, so most likely these are out of scope of SL1. Wanted to get agreement on this
    • George: trying to rationalize this against OpenID Connect first/last name. Even if SL1 is just about SSO, you still want user attributes. Is there an overlap with OIDC attributes and this or are they separated?
    • Dean: The way 63 does this is there is data you can get from the userinfo endpoint, OR you get data provided by the wallet. This work is more about the latter model, not about the userinfo endpoint
    • George: It sounds like the bigger piece is the wallet push model.
    • Dean: My sense (chair hat off) is in IPSIE we shouldn't do anything to say this is explicitly not allowed, but it's not something within the profile today. Maybe a future profile could use subscribed-held wallets, but it doesn't strike me as the most impactful thing in the enterprise today.
    • George: My understanding is SL1 is just about SSO, keeping the narrow scope is specifying what is required for that particular goal is really helpful. The lens should be what makes secure single sign-on. Things that don't support that goal are out of scope.
    • Dean: We will resolve this as being out of scope of SL1, will leave it open for a week and then close.

FAL2 Privacy Controls

https://github.com/openid/ipsie/issues/81

  • Dean: This doc has a very american specific view of privacy, that I don't think we can enforce a set of controls around since IPSIE covers more than the US. We can recommend you do have some privacy requirements, but we shouldn't define the requirements in IPSIE. Open to discussion before we make any decisions.
  • Karl: One thing we could do is make sure the IdP can support encryption of the assertion and identity claims, but not requiring that the RP does it. I could see requiring support of the claims request parameter for example. Not sure we want to go that direction but it's one way we could.
  • Dean: Let's leave this one open, would appreciate Karl's comments on the issue.

FAL2 Security Controls

https://github.com/openid/ipsie/issues/82

  • Dean: This is taking a very american perspective on a security program. We shouldn't make this normative, we could recommend you should have a security program, but not dictate which one.
  • Karl: We do mention TLS and MFA assurance requirements, those sound like security controls. I don't know where these map in to things here.
  • Dean: There are things in 800-53 that are relevant, but I'm not sure we want to take on that burden to define specific controls.
  • Mike: If we say something like "you have to conform to local requirements" that doesn't facilitate interoperability. If we choose a set of technical requirements and say everyone has to conform, that does promote interoperability. Basing the requirements on a US document doesn't change the interop requirements.
  • Dean: Having gone through 80053 and FEDRAMP a lot of the controls are internal, not affecting interop.
  • Mike: My comments were directed about attributes that would facilitate or not interoperability.
  • Dean: Do you think we should look through 80053 or FEDRAMP and try to pull out controls that affect interop (TLS, DNSSEC, etc)?
  • Mike: That is an accurate representation of my position
  • Karl: Clear mapping of what security controls that can be implemented that help tell an RP what they gain by implementing IPSIE. How can IPSIE say here's how you can accelerate your journey, not only interop but also gives you some of these security controls.
  • Dean: Is that a future IPSIE profile or is that a doc that rides alongside IPSIE, since they change over time
  • Karl: It's not in the interoperability profile, it's a separate document with its own lifecycle. we'll have to version IPSIE over time. Don't want to lose sight that the mapping is useful from an enablement perspective.
  • Dean: Sounds like two action items coming out of this. Because we're going to have some similar controls across all the profiles, we probably need to pull some of those out into their own doc that get applied across IL and SL levels. The second action item is to figure out how we deliver the security controls guidance to align with 80053 or FEDRAMP or others.
  • Karl: 👍

FAL2 Compliance - Authentication and Attribute Disclosure

https://github.com/openid/ipsie/issues/77

  • Dean: In section 3.6 it requires controls that sound more like business requirements rather than interop.
  • Kenn: Is this about the OIDC/OAuth consent prompt?
  • Dean: No, this is about the attributes shared between IdP and RP. The idea is to minimize disclosure. My sense is in IPSIE we need the business to determine what is shared.
  • Karl: As long as we have the capability to have bare minimum requirements (pairwise ID, no PII) as long as it can be deployed this way that's enough. What we define as the base level shoudln't prevent you from dialing it down to the minimum described in FAL2.
  • Dean: Both in SCIM and OpenID we'll need to define a minimum required for interop, which should be in line with the FAL2 guidance of being able to minimize attribute sharing.
  • Dean: Will leave this one open and add commentary from today's discussion.

FAL2 Trust Agreements and IPSIE

https://github.com/openid/ipsie/issues/76

  • Dean: requires trust agreements between services. I don't think these are technical controls.
  • Karl: is there value in defining a template trust agreement?
  • Aaron: Are we trying to help people meet FAL2, or are we using FAL2 as a shorthand for security features?
  • Dean: The trust agreements aren't part of interop
  • Shannon: Not necessarily true for multilateral federations, but yes for bilateral
  • Dean: Is that part of interop? or is it more about the business requirements in the multilateral federation?
  • Shannon: In a managed federation like incommon, the trust agreement faciliates interop because evryone agrees to certain practices
  • Karl: My understanding as well
  • Dean: If we say you must have a trust agreement and this is what it looks like, is that within scope of our influence?
  • Shannon: I think it would be difficult to influence bilateral trust agreements, but it changes with multilateral
  • Dean: So when we get to multilateral definitions within IPSIE is that when we get to needing to develop trust agreements? Do we need to do this in the next 6 months for interop, or is this a longer term thing?
  • Aaron: I don't think this is relevant for the next 6 months
  • Karl: The value of SL1 is independent of solving the trust agreement problem
  • Dean: Should we put work on trust agremeements on hold until after SL1?
  • (general agreement)
  • ACTION ITEM: flag this to revisit
  • Karl: What we're trying to do with SL1 is to look at FAL2 and look for things that will move baseline security forward. But the goal of SL1 is not to be comprehensive of FAL2 compliance.
  • ACTION ITEM: Make sure this is captured in the description of the levels

AOB

Dean: Will miss the next meeting, so will pick up the rest of the FAL2 issues in 2 weeks