Skip to content

2024‐12‐03

Jump to bottom
Aaron Parecki edited this page Dec 3, 2024 · 2 revisions

Date: 2024-12-03

Attendees

  • Aaron Parecki (Okta)
  • Dick Hardt (Hellō)
  • Dean H. Saxe (Beyond Identity)
  • Tom Clancy (MITRE)
  • Sean Miller (RSA)
  • Kenn Chong (RSA)
  • Shannon Roddy (Self)
  • Frederico Valente (Workday)
  • Erik Gomez (JGSW)
  • Jon Bartlett (Zscaler)
  • Shawn McGuire (Riot Games)
  • Brian Soby (AppOmni)
  • Jen Schreiber (Workday)
  • Pamela Dingle (Microsoft)
  • Nagesh Gummadivalli (Workday)
  • Tim Cappalli (Okta)
  • Filip Skokan (Okta)
  • Apoorva Deshpande (Okta)
  • George Fletcher (Capital One)
  • Bjorn Hjelm (Yubico)

Agenda

Minutes

Notetaker: Dean H. Saxe

  • Aaron: Picking up from last week's user stories originally written by Tim Cappalli
    • Now on gitHub in ipsie-v1-draft.md - https://github.com/openid/ipsie/blob/main/ipsie-v1-draft.md
    • Dean: We should look at this now, see what we want to add/remove
    • Aaron: David Brossard added a few PRs which have been merged. Matt's PR still waiting to be merged
    • Dean: Let's review, add some more definitions, get this ready to spin up subgroups
    • Aaron: Reviewing Matt Topper's PR (#7)
    • Pam: Is this just a move of content or changes?
    • Aaron: Both. Reorg of topics, expansion of topics, and new topics
    • Tim: Reasonable to ask him to resubmit as new PRs - one that expands on existing content, one that adds net new.
    • Aaron & Dean agree with Tim's comment
    • Pam: do we have a definition of B2B SaaS dev or B2B?
    • Aaron: How do find the right level of definitions?
    • Tim: Overview section? Keep working on it for now, figure that out later
    • Dean: Agree.
    • Aaron: Let's make sure we're all talking about the same thing - shared understanding.
    • Tim: Will add a PR and link to Pam's new issue.
  • Jen: looking at PR 10 - what does the endpoint mean?
    • Dean: endpoint is the computing Device.
    • Aaron: Editing this to change to device
    • Tim: This is a diff. component - thinking of an enterprise SaaS app, they just want to know that something has changed and they should take action.
    • Dean: I've seen both patterns - SaaS apps wanting raw signals vs. IdP as the policy engine
    • Tim: that's an oepn ended question
    • Gennady: IdP is not a policy engine unless that's what we plan to do. IdP doesn't know what the SP needs. Not sure where
    • Dean: BI offers a policy engine at the IP, SGNL offers one at the RP, these can be in conflict
    • Tim: Policy engines run at the IdP and at the RP, but customers do not want two... can we take a strong position on the "right" way?
    • George: State it differently - enterprise wants to define the policy through which their entities access the SaaS apps. e.g. if location changes, you must step up. How does the enterprise tell the SaaS app what the policy is per user? Framing is coming from an enterprise perspective. How do enterprises distribute this policy?
    • Shannon: Multilateral federations cannot hold a policy engine at the IdP. RP knows its data and responsibilities, IdP operator does not know this in Shannon's realm.
    • MikeJ: Agrees.
    • Aaron: We're heading a bit off track - but this is the opposite of enterprise and b2b SaaS.
    • Shannon: I have both 1:1 and multilateral federations.
    • Aaron: multilateral are not in IPSIE's scope
    • Shannon: How do we define enterprise? DoE does multilateral and bilateral federations
    • Aaron: ensure we narrow the scope for v1 that allows us to get work done.
  • BrianS: If anything believes it is capable of being a policy engine, let it be a policy engine! This doesn't make us enforce a hard rule
  • Pam: Agreed. Let's not be opinionated on this point. Talk about what's going over the wire and define protocols
  • George: Agree, no single policy engine. Need a way for an enterprise to assert its policy over the users of the SaaS app.
  • Shannon: in his federations, IdP sends data to RP which allows the RP to make policy decisions
  • Aaron: We probably can't tell people where to put a policy engine. If we frame this around workforce applications (thanks Tim!) it simplifies the discussion
  • Pam: likes the approach. Uses the example of acr as an essential request.
  • Sean: Not a requirement, but an option for signalling?
  • Dean: We shouldn't mandate whether a SaaS app accepts signals
  • Gennady: IdP cannot initiate the signal except when authN is requested. IdP can process data via policy.
  • Dean: Disagree - signals originate from many places, sent to many destinations
  • Gennady: Should we separate identity and signals?
  • Aaron: We can't make this decision - businesses have a lot of different operational needs.
  • Aaron switches to PR 13 https://github.com/openid/ipsie/pull/13 to scope the conversation
  • Pam: Define workforce for shared understanding - employees, contractors, any disagreement? Pam will add to her issue https://github.com/openid/ipsie/issues/12
  • Shannon: my env is different. My workforce can also be my customers (and often are).
  • George: Consultants?
  • Pam: they are also workforce
  • Gennady: this can cause issues
  • Dean: Let's not get into the legal definitions
  • Dean / Aaron: Look at PR 11, step up / re-authN
  • Aaron: They belong in the same part of the doc, even if they are different items.
  • Dean: I will update PR11 https://github.com/openid/ipsie/pull/11
  • George: we're trying to convey policy, which isn't always authN (e.g. I need a specific IAL). This is communicating data between the App and the IdP, the data we communicate may be somewhat arbitrary (e.g. AAL, IAL, etc.) The IdP and SaaS apps both have policy and need to resolve them at some point in time.
  • Dean: This gets back to signalling - we've gone full circle
  • George: Broader than shared signals (Dean agrees)
  • Aaron: Add those items to this list (request to George)
  • Jon: Are we putting attributes in the draft for IPSIE v1?
  • Aaron: Attributes other than authN, not a specific vocabulary =)
  • Dean: Let's start adding protocols/mechanisms under the topline headlines (e.g. provisioning -> SCIM + others). Not choosing winners/losers yet.
  • Aaron: Join slack if you have not yet. Used for conversations. New channel #wg-ipsie-feeds for all github notifications.
Clone this wiki locally