<div dir="ltr"><div>Apologies, I forgot to send the meeting minutes to the list after last week's call. They are pasted below. Thanks to Dean for taking notes.</div><div><br></div><div># IPSIE WG Meeting Minutes<br>Date: 2025-04-29<br><br>## Attendees<br><br>* Aaron Parecki (Okta)<br>* Dean H. Saxe (Beyond Identity)<br>* Jon Bartlett (Zscaler)<br>* Filip Skokan (Okta)<br>* Mark Maguire (Aujas Cybersecurity)<br>* Dick Hardt (Hellō)<br>* Travis Tripp (HPE)<br>* Keiko Itakura(Okta)<br>* Hirsch Singhal (GitHub)<br>* Karl McGuinness (Self)<br>* Tim Cappalli (Okta)<br>* Usha N (GitHub)<br>* Wes Dunnington (Ping)<br>* Shannon Roddy (Self/LBL)<br>* Alex B Chalmers (Self)<br>* Bjorn Hjelm (Yubico)<br><br><br><br>## Agenda<br><br>- Welcome and antitrust policy reminder <a href="http://www.openid.net/antitrust">www.openid.net/antitrust</a><br>- OpenID Contributor Agreement reminder <a href="https://openid.net/intellectual-property">https://openid.net/intellectual-property</a><br>- Reminder about OpenID Slack<br>    - invite link: <a href="https://join.slack.com/t/oidf/shared_invite/zt-30zg9louv-3HgJEwIL7vB3uWv2KEbLtw">https://join.slack.com/t/oidf/shared_invite/zt-30zg9louv-3HgJEwIL7vB3uWv2KEbLtw</a><br>- Community Events<br>    - RSA this week<br>    - EIC May 6-9<br>    - AuthCon May 14<br>    - SaaStr May 13-15<br>    - Identiverse June 3-6<br>- JP Morgan Chase Open Letter<br>- Review profiles & issues<br>    - Recently closed: <a href="https://github.com/openid/ipsie/issues?q=label%3Asl1+is%3Aclosed">https://github.com/openid/ipsie/issues?q=label%3Asl1+is%3Aclosed</a><br>    - Open issues: <a href="https://github.com/openid/ipsie/labels/sl1">https://github.com/openid/ipsie/labels/sl1</a><br>        - ISO vs IETF keywords <a href="https://github.com/openid/ipsie/issues/68">https://github.com/openid/ipsie/issues/68</a><br>- AOB<br>    <br><br>Notetaker: Dean H. Saxe<br><br>## Minutes<br>- Antitrust & Contributor Agreement reminder<br>- Dick added AuthCon.io to the list of upcoming events<br>    - Dick is speaking about IPSIE<br>- JPMC Open letter discussion [link](<a href="https://www.jpmorgan.com/technology/technology-blog/open-letter-to-our-suppliers">https://www.jpmorgan.com/technology/technology-blog/open-letter-to-our-suppliers</a>)<br>    - relevant to IPSIE<br>    - call to action for SaaS providers to increase their security when integrating with enterprise companies<br>    - OIDF is considering a response to this doc - relevance of IPSIE, AuthZen, AB Connect WGs<br>- SAML recap<br>    - Want to make progress on OIDC profile, prioritizing this work<br>    - we aren't spending meeting time on SAML at this time<br>    - it is not clear that we'll be able to meet  the same security profile for SAML, so it's unclear if we call it SL1 or something else <br>    - Dick: Agrees with focus on OIDC right now. We won't get industry interest without SAML.  <br>        - Raises concerns that we need to support SAML at SL1 to bring the industry along.<br>        - Dick: If SAML can't meet SL1, what do we do? Without the same features as OIDC at SL1, it's not the same thing.<br>        - Aaron: Can we develop a SAML profile with an upgrade path to move to OIDC?  <br>        - Dick is concerned about the practicality of this idea<br>        - Mark M. - need clarity. What does SAML need to do to meet SL1?  If it meets the requirements is it as secure as OIDC at SL1?  <br>        - Can we meet FAL2 with SAML?<br>        - Dean: First pass, yes, but I need to discuss with SAML experts.<br>        - Tom Clancy (in chat): The main "gap" for FAL2 tailored for PIV transactions is injection protection using backend flow--need to specific artifact binding-type SAML profile.<br>        - Dick: Can we agree that the high bar for SAML is SL1? Wants to ensure SAML can meet *at least* SL1 so that we have a profile at SL1.<br>        - Shannon: My IdP can meet FAL2 based on a quick review<br>        - Aaron: Need more concrete patterns to show how a SAML impl is configured to meet SL1 <br>        - Dick: Tighten up SAML as much as possible w/o adding new features should be the goal.<br>        - Karl: How do we make this easier to sell to PMs in SaaS companies who already invested in SAML and don't use OIDC.  Thinks FAL2 compliance is a huge lift.<br>        - Aaron: So the SAML profile lays out what it means to be secure, can identify the cost to upgrade vs moving to OIDC.<br>        - Aaron: Is anyone willing to spend time to document what the implementation changes needed are to meet FAL2?<br>        - Alex C: Will review SAML vs FAL2 once Dean writes the FAL2 issue. Shannon will assist.<br>        - tom C in chat: NIST SP 800-217fpd includes tailoring of FAL 2: SP 800-217, Guidelines for Personal Identity Verification (PIV) Federation | CSRC<br>- Issues<br>    - Aaron reviewed 61 & 63, confirmed text was updated in SL1 OIDC draft, closed issues<br>    - 68 - ISO vs IETF keywords<br>        -  original idea for ISO was to use their keywords in FAPI<br>        -  ISO has adopted OIDF docs using IETF keywords<br>        -  Aaron has a PR with the keywords changed to ISO <br>        -  Dean can review and accept if there are no disagreements.  None heard, Dean will review.<br>        -  s/shall/MUST/ for IETF keyword alignment<br>    -  64 - discussed last week, keeping the SHOULD for DNSSEC<br>        -  draft did not include idtoken validation<br>        -  Aaron added a PR <br>        -  (Dean: This is required at FAL2, iirc)<br>        -  Mark confirms this looks good.<br>        -  Dean can review and merge, no disagreement heard on the call<br>        -  this will allow us to close 64 once merged<br>    -  60 & 62 - related issues that are going to AB/Connect<br>        -  we agreed previously about moving these to AB/Connect<br>        -  Dick was going to follow up<br>        -  Dick: in AB/Connect looking for info on how to define tenancy<br>            - Dick has writing these claims in his queue.<br>            - He will bring this to AB/Connect for adoption<br>            - Filip: Tenant going to AB/Connect, session lifetime doesn't seem like it needs to go there.  <br>            - Aaron: If IPSIE needs to add features to a spec, we should first try to do that in the spec's original WG if the feature is not specific to IPSIE.<br>            - Filip: This will be misused by RPs, forcing prolonged lifetime for the idtoken... <br>            - Aaron: Not discussing idtoken, but it's an interesting point.  Is this an IPSIE specific feature?<br>            - Karl: general session management in OIDC is where this likely belongs. Related to SSF. IPSIE defines constraints on how lifetime is implemented, OIDC is incomplete with session management.  This brings clarity.<br>            - Dick: discussion around idtoken additions belong in the WG handling idtokens (e.g. ab/connect).  Doing the work in AB/connect gets a broader set of eyes on the changes. Proposed spec is "OIDC Enterprise Extensions".  Will leave this open to add other additions for SL*n* as needed<br>        - Aaron: We'll keep this as a standing item to check in on.<br>    - 67 - `acr` claim<br>        - currently required in SL1 sec 3.3.1<br>        - what do we do to describe the `acr` when a string does not yet exist to describe simple authN?<br>        - Dean: chair hat off - don't bind to AAL2, figure out terminology for "MFA" that we can use.  Don't require phishing resistance, even if we know it's a good requirement.<br>        - Karl: there is value in providing both acr and amr, would still be able to indicate what methods were used even if they don't meet a context class.  Do we fall back to the amr problem where it's subject to interpretation?  phr is a clear level of outcome, everything else is subject.<br>        - Aaron: if an RP requires MFA, they can know it has been met.  SL2 must repect the 'amr' request.  Aaron suggests SL1 requires both 'acr' and 'amr'.<br>        - Karl: this tracks with my memory.<br>        - Aaron/Dean: We need to capture this change in an issue and change the SL1 profile.  Need to determine what happens if no context class is met (as in this issue).<br>        - Aaron: idtokens from IdP must ALWAYS have `amr` & `acr`.<br>        - Karl: only `amr` in the idtoken<br>        - Filip: if a claim is empty/null it should be missing instead of empty.  May not be allowed in JWT.<br>        - Aaron: What does OIDC say about when `acr` is included? Is that sufficient for IPSIE?<br>        - Aaron will write a PR.<br>- AOB<br>    - Dean:  SCIM - need to get to work on IL1.  Mark is working on a rough draft with Jen.  Need more use cases defined, clarified for a minimum bar<br>    - MarkM is working on a draft with Jen, will share soon.<br><br><br></div><div><br></div><div><br></div></div>