Skip to content

2025‐07‐01

Jump to bottom
Aaron Parecki edited this page Jul 2, 2025 · 1 revision

IPSIE WG Meeting Minutes

Date: 2025-07-01

Attendees

  • Dean H. Saxe (self)
  • Aaron Parecki (Okta)
  • Karl McGuinness (selfie)
  • Filip Skokan (Okta)
  • Dick Hardt (Hellō)
  • Alex B Chalmers (Self)
  • Monika Avalur(CyberArk)
  • Mike Kiser (SailPoint)
  • Jen Schreiber (Workday)
  • Jon Bartlett (Zscaler)
  • Yuval Glasner (CyberArk)
  • Gennady Shulman (self)
  • Qinglan Hsu (RSA)
  • Travis Tripp (HPE)
  • Shannon Roddy (self/lbl)

Agenda

Notetaker: Aaron Parecki

Minutes

Dean: Enterprise Extensions update from Connect WG? Dick: Some updates on account resolution to discuss

PR #3

  • Dean: Made updates to OIDC SL1 intro (PR #3)
  • Dean: Would like to discuss today to get agreement on what is in scope for the intro, mainly that it is about federation but not API access
  • Monika: Question about federated authentication. Is this only talking about one particular flow?
  • Dean: The levels describe the outcomes that each profile is trying to achieve. The SL series talk about session lifecycle. At SL1 there are specific obligations for the RP and IDP. The specific guidance is in this document. The intro is capturing that at SL1 we are not going to be handling any generic API access.
  • Aaron: it provides the one definition of how to use OpenID Connect for federated authentication
  • Dick: We had a conversation about extending a session with a refresh token to get a new ID token
  • Aaron: The intro text should be more clear about the out of scope (refresh token and DPoP) being relevant to API access, not ID tokens
  • Jen: It's a bit too specific, it should be either broader or list "in scope out of scope" more specifically.

IPSIE Common Requirements Profile

  • Dean: We hd talked about a sidecar doc, intended to apply to all the different profiles we create that has common requirements like TLS, DNSSEC, etc. Have received virtually no feedback on the text to date. Hopefully resolves a number of issues we've listed. Wanted to get some feedback on whether this looks reasonable enough to call for working group adoption of the document. The reason we want to do this is it doesn't make sense to rewrite the guidance across multiple documents.
  • Jen: My biggest question is you mentioned details on encryption at rest, should probably be out of scope. This shouldn't stop adoption, we can figure it out later.
  • Aaron: this doesn't seem to impact interop, should be out of scope entirely
  • Dean: TODO remove the security controls section
  • Alex: When we had originally talked about language similar to this it was advisory, but not normative.
  • Jen: I don't think it adds much
  • Jen: What is the role of the Federation section?
  • Dean: Trying to align with security controls of FAL2. It's hard to decide which of the FAL2 controls to adopt or not. Not tied to this text, happy to remove things if needed.
  • Jen: My recommendation is the items marked as recommended don't fit the interop model. We can take a stronger stance on them or remove them.
  • Dean: you can leave comments or make edits here: https://github.com/openid/ipsie/pull/71
  • Aaron: So we'll wait for the call for adoption until these changes are made
  • Dick: The markdown in 3.4 is broken. I'm supportive of having something like this. I assume it'll be iterated on as we work through this.
  • Dean: The call for adoption is not the final text. Assuming we adopt this, we can then remove the common guidance from the OIDC and SAML profiles too.

Account Resolution (#79)

  • Dick: How do we make it easier for an RP to resolve accounts from IDP. Karl shared in Okta they included an RP identifier to the OP and the OP would provide that claim in addition to the sub to identify the account. So the RP can get its own identifier back all the time.
  • Karl: The question is how does the OP get the RP identifier. People do it today with manual export, or with SCIM. Lots of existing paths to get the identifiers into the OP.
  • Dean: Would love to see this written down a bit more.
  • Karl: The enterprise has the ability to manage the data store for a set of users in an app. In a personal context it would be hard to manage the boundary. The OP is effectively asserting the identity rather than JIT. So it's an account takeover vector. In brownfield enterprise you are effectively doing an account takeover but in a controlled way. So enterprise has a way to talk about that, but not on the consumer.
  • Karl: This is effectively how microsoft SSO works.
  • Travis: This used to be called AD Connect
  • Karl: The suggestion is the pattern of specifying the RP's identifier in a claim is valuable in a brownfield use case if we define what the claim is for account resolution purposes. Avoids needing to JIT a user and avoids falling back on email for account linking.
  • Travis: So the suggestion is to have a named claim for this. It would be useful for us.
  • Dean: This also in some cases resolves the global uniqueness issue, since the identifier is not intended to be globally unique.
  • Karl: Yeah, the identifier is in the context of the RP
  • Travis: If I'm the RP, the user puts in their email domain and we route them. We require you create a DNS entry to claim a domain. The org owns IDP connection routing for that domain. If you have two different IDPs and they attempt to send in the same user how does that work?
  • Karl: Dick and I started talking about this in the context of OP Commands. The need to have an explicit operation to bind an account to an OP. That's complementary but this solves a specific problem.
  • Travis: Within the context of a tenant, the posix ID has to be unique, the owner of the tenant controls that. But from an email domain perspective, that has to have a unique source of truth for all tenants.
  • Karl: This would be a claim specific to the RP tenant (the posix ID) in the new claim. For authentication you can bind to this new claim.
  • Monika: You can specify email as a routing rule, but authentication can happen using a different claim. Are we trying to standardize the claim at which this should happen?
  • Karl: Yes for account resolution which is part of authentication. If there is an existing account, what does IPSIE want to say about account resolution. Right now there are no other identifiers than email, which has a bunch of challenges. The proposal Dick and I were exploring was defining a new claim in the token
  • Monika: Crypto sends an ID in the token but not email.
  • Dean: One of the reason IPSIE exists is because of this problem. There's a lot of options in the specifications. The work of IPSIE is to narrowly scope what is implemented in order to raise the interop bar.
  • Monika: There are uses where they might want to map one user to multiple IDPs and let the user choose which to log in to. Like social login. Would the standard claim support that?
  • Karl: The claim doesn't dictate the model in the RP of 1-1 or 1-many. The question for IPSIE is do we want to define IDP discovery or other things, but that doesn't impact what we're proposing with this claim.
  • Dean: We're not going to define net new things in IPSIE except as a last resort, we'd prefer to do those elsewhere like OP Commands in AB Connect.
  • Dick: We'll work on this and present in AB Connect. The goal of bringing it up here was to get feedback from this group. We also have thoughts on how this fits into OP Commands. Further discussion will happen in the AB Connect group for those interested.
  • Monika: Are we talking about JIT here or just account resolution assuming the user already exists
  • Dean: The two are linked. The specific work is about account resolution. However is in IPSIE what we've said so far is IPSIE doesn't specify how JIT provisioning works but does specify that if you are going to provision a user via JIT, the user needs to be brought under control of the IDP.
  • Dick: I think we're still going to have a discussion about account resolution, all this is is an identifier.

JIT Provisioning at SL1 (#88)

  • Dean: Rather than using time on the call for this I'd appreciate if folks took some time to review this offline.
  • Dick: Filip and I will make a bunch of progress at IETF

The auth_time claim (#89)

  • Dean: At FAL2, the security control is that the RP should be able to say what the max auth age is at federation. Auth time represents the time the IDP last authenticated the user. Prompt comes in to be able to force a reauthentication event. I talked with Justin Richer (one of the 800-63C authors). One thing that came up last week is what if the IDP is using risk based authenticaiton? If you auth at time T0 with a passkey, then at T+5 minutes the RP asks max age less than 5 minutes, can the IDP update the auth time claim based on risk assessment? The answer I got from Justin is that the auth time is what started the session, but said that risk engine evaluation could be considered authentication, but there's no way to indicate that. So if we are making an auth time claim, we should always pair that with an amr claim. During the first would use phr (passkey), when the risk based auth occurs we can make amr=rba claim. I don't know if this is the right path forward but it seems correct. Would like feedback from others.
  • Karl: 👍
  • Bertrand: I like that we use amr to describe risk based auth. But then we lose whether the first auth was password or phr. So maybe we should use multi-valued amr.
  • Dean: Was difficult to hear, but what I think I heard is you generally like this but how does the RP know what type of auth was used prior to the rba auth time
  • Karl: Yes you can provide multiple values. The gap is going to be around does the RP need more evidence like what was primary and secondary. amr is coarse grained today. For example we can't provide timestamp per amr.
  • Bjorn: Support utilizing amr
  • Dean: We're at time for today.
Clone this wiki locally