[Openid-specs-ipsie] 2025-05-13 Meeting Minutes

Fri May 16 03:30:06 UTC 2025

 Hi all, the minutes from this week's call are below, as well as posted on
GitHub.

# 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

- 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
    - AuthCon May 14
    - SaaStr May 13-15
    - Identiverse June 3-6
- Review profiles & issues
    - Recently closed:
https://github.com/openid/ipsie/issues?q=label%3Asl1+is%3Aclosed
    -
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%20FAL2%20label%3Asl1

Notetaker: Dean H. Saxe and Aaron Parecki

## Minutes
- We will cancel the WG call during the Identiverse conference

### Review profiles & issues
- Recently closed:
https://github.com/openid/ipsie/issues?q=label%3Asl1+is%3Aclosed
    - Nothing new since last week
    -
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
- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20250515/5b11a883/attachment-0001.htm>