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