<html><body><div dir="ltr">Hello,<div><br></div><div dir="ltr">I’ve posted the most recent meeting minutes at <a href="https://github.com/openid/ipsie/wiki/2025%E2%80%9003%E2%80%9025">https://github.com/openid/ipsie/wiki/2025%E2%80%9003%E2%80%9025</a>. I have also copied them below for convenience.</div><div dir="ltr"><br></div><div dir="ltr">Our next meeting will be at the regular time on April 1, 2025. Note that we will cancel the April 8, 2025 meeting due to the Internet Identity Workshop, where many members and the co-chairs will be during the normally scheduled meeting time.</div><div dir="ltr"><br></div><div dir="ltr">If you have any questions, please reach out to me or Aaron.</div><div dir="ltr"><br></div><div dir="ltr">Thanks,</div><div dir="ltr">-dhs</div><div dir="ltr"><br></div><div dir="ltr">######</div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"># IPSIE WG Meeting Minutes</div><div dir="ltr">Date: 2025-03-25</div><div dir="ltr"><br></div><div dir="ltr">## Attendees</div><div dir="ltr">- Dean H. Saxe (Beyond Identity)</div><div dir="ltr">- Jon Bartlett (Zscaler)</div><div dir="ltr">- George Fletcher (Practical Identity LLC)</div><div dir="ltr">- Shannon Roddy (Self/LBNL)</div><div dir="ltr">- Mark Maguire (Aujas Cybersecurity)</div><div dir="ltr">- Frederico Valente (Workday)</div><div dir="ltr">- Blake Lewis (okta)</div><div dir="ltr">- Sean Miller (RSA)</div><div dir="ltr">- Aboobacker MK (GitLab)</div><div dir="ltr">- Keiko Itakura(Okta)</div><div dir="ltr">- Tom Clancy (MITRE)</div><div dir="ltr">- Jen Schreiber (Workday)</div><div dir="ltr">- Dick Hardt (Hellō)</div><div dir="ltr">- Pat Buffolino (Paramount)</div><div dir="ltr">- Robin Martherus (Cisco)</div><div dir="ltr">- Karl McGuinness (Self)</div><div dir="ltr">- Travis Tripp (HPE)</div><div dir="ltr"><br></div><div dir="ltr">## Agenda</div><div dir="ltr"><br></div><div dir="ltr">- Welcome and antitrust policy reminder</div><div dir="ltr">- OpenID Contributor Agreement reminder <a href="https://openid.net/intellectual-property">https://openid.net/intellectual-property</a></div><div dir="ltr">- Reminder about OpenID Slack</div><div dir="ltr">- Update on upcoming call schedule - no call on April 8 due to IIW</div><div dir="ltr">- Update from IETF SCIM WG</div><div dir="ltr"> - SCIM Profile for IL1 </div><div dir="ltr">- Review profiles & issues</div><div dir="ltr"> - OpenID SL1 Editor's Copy - <a href="https://drafts.aaronpk.com/ipsie-openid-sl1/draft-openid-ipsie-sl1-profile.html">https://drafts.aaronpk.com/ipsie-openid-sl1/draft-openid-ipsie-sl1-profile.html</a> </div><div dir="ltr"> - Open issues - <a href="https://github.com/openid/ipsie/labels/sl1">https://github.com/openid/ipsie/labels/sl1</a></div><div dir="ltr"> - Tenancy - <a href="https://github.com/openid/ipsie/issues/62">https://github.com/openid/ipsie/issues/62</a></div><div dir="ltr"> - Session Lifetime --> Directives? - <a href="https://github.com/openid/ipsie/issues/60">https://github.com/openid/ipsie/issues/60</a></div><div dir="ltr"> - Confidential Clients - <a href="https://github.com/openid/ipsie/issues/61">https://github.com/openid/ipsie/issues/61</a></div><div dir="ltr"> - Access Tokens - <a href="https://github.com/openid/ipsie/issues/63">https://github.com/openid/ipsie/issues/63</a></div><div dir="ltr"> - To PAR or Not to PAR - <a href="https://github.com/openid/ipsie/issues/59">https://github.com/openid/ipsie/issues/59</a></div><div dir="ltr"> - SAML SL1</div><div dir="ltr">- AOB</div><div dir="ltr"> </div><div dir="ltr"><br></div><div dir="ltr">Notetaker: Jen Schreiber, Dean Saxe, Tom Clancy</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">## Minutes</div><div dir="ltr"><br></div><div dir="ltr">- IPSIE at IETF in SCIM working group</div><div dir="ltr"> - SCIM could be used in IL controls</div><div dir="ltr"> - Dean to act as bridge between SCIM wg and OIDF/IPSIE</div><div dir="ltr">- IL1 - SCIM - Jen & Mark Maguire to work on an initial profile</div><div dir="ltr"> - Karl suggests to check out FastFed</div><div dir="ltr">- SL1 issues</div><div dir="ltr"> - Dick: no updates from AB connect</div><div dir="ltr"> - Issue #60: how to let idp dictate RP session lifetime in OIDC</div><div dir="ltr"> - Karl: many use cases for this but no clear way with dynamic access management to do this. do we want to go back to AB and define a generic method?</div><div dir="ltr"> - Dean: we are talking about directives from the OP that the RP MUST follow/take action from. this is different from SSF.</div><div dir="ltr"> - Dick: likes focus on session on session timeout. proposes to do so in AB wg</div><div dir="ltr"> - George: been talking to SSF authors, the idea that a signal is not a directive may become gray. we shouldn't discount using SSF for this purpose, it could be leveraged.</div><div dir="ltr"> - Dean: what is the intersection here? ssf? directives?</div><div dir="ltr"> - Karl and George want to tackle this in a generic way by starting with the action itself (like session timeout)</div><div dir="ltr"> - Dick: if we want to specify the session timeout, then it should be specified in the token</div><div dir="ltr"> - Dean: worries about using SSF for SL1 because of effort to implement.</div><div dir="ltr"> - Consensus: Include a claim in the id token (go back to ab connect wg) to define session length for SL1.</div><div dir="ltr"> - Consensus: Roll changes for IPSIE into one document for ab conect wg. put time limit on this so it doesnt delay anything for IPSIE</div><div dir="ltr"> - Issue #61: Confidential clients. Do we want to require confidential clients? SL1? SL2?</div><div dir="ltr"> - Issue #63: Access Tokens</div><div dir="ltr"> - Karl</div><div dir="ltr"> - ATs are not necessary for SSO</div><div dir="ltr"> - if we focus on SSO, can we profile to reduce the requirements to PKCE, TLS, etc. using a public client at SL1. </div><div dir="ltr"> - Risk is balanced by not having long-lived access</div><div dir="ltr"> - Aim is for max deployability, confidential clients adds overhead that may not be supportable at SL1</div><div dir="ltr"> - Dick - aligned with Karl's thoughts</div><div dir="ltr"> - George </div><div dir="ltr"> - in an enterprise B2B scenario, what's the expectation if they don't want to support public clients at SL1? Are SL1 confidential clients possible?</div><div dir="ltr"> - Is public vs. private orthogonal to SLx?</div><div dir="ltr"> - Travis</div><div dir="ltr"> - Supports what Karl said above</div><div dir="ltr"> - Confidential clients don't work in all of his customer situations</div><div dir="ltr"> - Looking at different session types - UI, CLI, etc</div><div dir="ltr"> - Which concept are we discussing?</div><div dir="ltr"> - dean - Sounds liek a web context</div><div dir="ltr"> - Dick - responding to George</div><div dir="ltr"> - what if someone wants a confidential client? Have to be prescriptive</div><div dir="ltr"> - SL1 requires disabling confidential clients?</div><div dir="ltr"> - Karl - end customer doesn't define IdP/RP as the security boundary</div><div dir="ltr"> - Travis was talking about the CLI app as the client/session (e.g. github app)</div><div dir="ltr"> - app level session context is first party, created by the IdP session</div><div dir="ltr"> - Customer is interested in the outcomes</div><div dir="ltr"> - What if an app needs more than what the IPSIE SLx profile offers?</div><div dir="ltr"> - e.g. needs access tokens? Do I need DPoP?</div><div dir="ltr"> - Real world use cases may not map cleanly to SLx, so how do we handle these?</div><div dir="ltr"> - raise the bar for everything?</div><div dir="ltr"> - Downside is a lot of overhead for every client</div><div dir="ltr"> - Dean - how do we leave the door open to SL1 with confidential clients?</div><div dir="ltr"> - Karl</div><div dir="ltr"> - IdP requirements are MUST - public client</div><div dir="ltr"> - IdP MUST support private client at SL1</div><div dir="ltr"> - push more requirements on IdP and less on RPs</div><div dir="ltr"> - George</div><div dir="ltr"> - I think of the enterprise as the primary driver for requirements</div><div dir="ltr"> - Is it valuable over the long term for an RP to say I'm good enough as a public client?</div><div dir="ltr"> - Are we looking at this from IdP, RP, or enterprise perspective?</div><div dir="ltr"> - If enterprises are only ever only going to start at SL2, what is the value of SL1?</div><div dir="ltr"> - Dean</div><div dir="ltr"> - IdPs--what do you think? </div><div dir="ltr"> - Karl</div><div dir="ltr"> - There's value in Sign-in with Google for phishing-resistance -- there's a lot of security stuff outside the IdP boundary that provides security value</div><div dir="ltr"> - Dean</div><div dir="ltr"> - We seem to think we can include public clients at SL1 and confidential clients at SL2</div><div dir="ltr"> - For access tokens, we seem to think they are also SL2 and above... (Dick agrees)</div><div dir="ltr"> - "At SL1, IdPs MUST support public clients; if you are issuing access tokens, you must require SL2"</div><div dir="ltr"> - George</div><div dir="ltr"> - I agree with the risk lens for access. Which is why I’m not sure public vs confidential clients is even relevant to IPSIE</div><div dir="ltr"> - We seem to be saying we won't leverage FAPI for SL1</div><div dir="ltr"> - If there's no requirement for sender-constrained access tokens, public or confidential doesn't matter</div><div dir="ltr"> - Like Karl said "if public client is accessing _, the IDP must do _"</div><div dir="ltr"> - Dean</div><div dir="ltr"> - Consideration: what if you want to require SL1 but your business requires confidential client</div><div dir="ltr"> - George</div><div dir="ltr"> - How the client got registered will determine whether it's confidential or public</div><div dir="ltr"> - It's fundamental and determines the rest of the requirements</div><div dir="ltr"> - You can specify the requirement for client authentication and the rest is determined</div><div dir="ltr"> - Karl</div><div dir="ltr"> - IPSIE profile needs to follow through on the combinations of optionality by supporting a la carte</div><div dir="ltr"> - The thread modeling become complex -- you may as well just adopt FAPI</div><div dir="ltr"> - The ROI for a la carte is slim</div><div dir="ltr"> - George</div><div dir="ltr"> - FAPI 2 for xL2, not at xL1</div><div dir="ltr"> - Karl</div><div dir="ltr"> - capture this clear decision</div><div dir="ltr"> - Dean</div><div dir="ltr"> - Need to make this more clear at SL1 </div><div dir="ltr"> - We don't need to make the decision for xL1, today</div><div dir="ltr"> - Dick agrees -- different for APIs not specific to SL1</div><div dir="ltr"> - </div><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">--<br><div dir="ltr">Dean H. Saxe, <a href="https://idpro.org/cidpro/">CIDPRO</a> (he/him)</div><div dir="ltr">Principal Engineer</div><div dir="ltr">Office of the CTO</div><div dir="ltr">Beyond Identity</div><div dir="ltr"><a href="mailto:dean.saxe@beyondidentity.com">dean.saxe@beyondidentity.com</a></div><div><br><div><br></div></div></div></div></div></div></div></body></html>