[Openid-specs-ipsie] 2025-04-29 Meeting Minutes
Aaron Parecki
aaron.parecki at okta.com
Tue May 6 15:49:15 UTC 2025
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.
# IPSIE WG Meeting Minutes
Date: 2025-04-29
## Attendees
* Aaron Parecki (Okta)
* Dean H. Saxe (Beyond Identity)
* Jon Bartlett (Zscaler)
* Filip Skokan (Okta)
* Mark Maguire (Aujas Cybersecurity)
* Dick Hardt (Hellō)
* Travis Tripp (HPE)
* Keiko Itakura(Okta)
* Hirsch Singhal (GitHub)
* Karl McGuinness (Self)
* Tim Cappalli (Okta)
* Usha N (GitHub)
* Wes Dunnington (Ping)
* Shannon Roddy (Self/LBL)
* Alex B Chalmers (Self)
* Bjorn Hjelm (Yubico)
## Agenda
- Welcome and antitrust policy reminder www.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
- RSA this week
- EIC May 6-9
- AuthCon May 14
- SaaStr May 13-15
- Identiverse June 3-6
- JP Morgan Chase Open Letter
- Review profiles & issues
- Recently closed:
https://github.com/openid/ipsie/issues?q=label%3Asl1+is%3Aclosed
- Open issues: https://github.com/openid/ipsie/labels/sl1
- ISO vs IETF keywords https://github.com/openid/ipsie/issues/68
- AOB
Notetaker: Dean H. Saxe
## Minutes
- Antitrust & Contributor Agreement reminder
- Dick added AuthCon.io to the list of upcoming events
- Dick is speaking about IPSIE
- JPMC Open letter discussion [link](
https://www.jpmorgan.com/technology/technology-blog/open-letter-to-our-suppliers
)
- relevant to IPSIE
- call to action for SaaS providers to increase their security when
integrating with enterprise companies
- OIDF is considering a response to this doc - relevance of IPSIE,
AuthZen, AB Connect WGs
- SAML recap
- Want to make progress on OIDC profile, prioritizing this work
- we aren't spending meeting time on SAML at this time
- 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
- Dick: Agrees with focus on OIDC right now. We won't get industry
interest without SAML.
- Raises concerns that we need to support SAML at SL1 to bring the
industry along.
- 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.
- Aaron: Can we develop a SAML profile with an upgrade path to move
to OIDC?
- Dick is concerned about the practicality of this idea
- 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?
- Can we meet FAL2 with SAML?
- Dean: First pass, yes, but I need to discuss with SAML experts.
- 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.
- 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.
- Shannon: My IdP can meet FAL2 based on a quick review
- Aaron: Need more concrete patterns to show how a SAML impl is
configured to meet SL1
- Dick: Tighten up SAML as much as possible w/o adding new features
should be the goal.
- 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.
- Aaron: So the SAML profile lays out what it means to be secure,
can identify the cost to upgrade vs moving to OIDC.
- Aaron: Is anyone willing to spend time to document what the
implementation changes needed are to meet FAL2?
- Alex C: Will review SAML vs FAL2 once Dean writes the FAL2 issue.
Shannon will assist.
- tom C in chat: NIST SP 800-217fpd includes tailoring of FAL 2: SP
800-217, Guidelines for Personal Identity Verification (PIV) Federation |
CSRC
- Issues
- Aaron reviewed 61 & 63, confirmed text was updated in SL1 OIDC draft,
closed issues
- 68 - ISO vs IETF keywords
- original idea for ISO was to use their keywords in FAPI
- ISO has adopted OIDF docs using IETF keywords
- Aaron has a PR with the keywords changed to ISO
- Dean can review and accept if there are no disagreements. None
heard, Dean will review.
- s/shall/MUST/ for IETF keyword alignment
- 64 - discussed last week, keeping the SHOULD for DNSSEC
- draft did not include idtoken validation
- Aaron added a PR
- (Dean: This is required at FAL2, iirc)
- Mark confirms this looks good.
- Dean can review and merge, no disagreement heard on the call
- this will allow us to close 64 once merged
- 60 & 62 - related issues that are going to AB/Connect
- we agreed previously about moving these to AB/Connect
- Dick was going to follow up
- Dick: in AB/Connect looking for info on how to define tenancy
- Dick has writing these claims in his queue.
- He will bring this to AB/Connect for adoption
- Filip: Tenant going to AB/Connect, session lifetime doesn't
seem like it needs to go there.
- 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.
- Filip: This will be misused by RPs, forcing prolonged
lifetime for the idtoken...
- Aaron: Not discussing idtoken, but it's an interesting
point. Is this an IPSIE specific feature?
- 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.
- 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
- Aaron: We'll keep this as a standing item to check in on.
- 67 - `acr` claim
- currently required in SL1 sec 3.3.1
- what do we do to describe the `acr` when a string does not yet
exist to describe simple authN?
- 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.
- 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.
- 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'.
- Karl: this tracks with my memory.
- 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).
- Aaron: idtokens from IdP must ALWAYS have `amr` & `acr`.
- Karl: only `amr` in the idtoken
- Filip: if a claim is empty/null it should be missing instead of
empty. May not be allowed in JWT.
- Aaron: What does OIDC say about when `acr` is included? Is that
sufficient for IPSIE?
- Aaron will write a PR.
- AOB
- 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
- MarkM is working on a draft with Jen, will share soon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20250506/f218eb59/attachment.htm>
More information about the Openid-specs-ipsie
mailing list