Brainstorming outcomes for IPSIE

[aaronpk]

Please use this issue to brainstorm outcomes you would like to be able to achieve with IPSIE. We will collect and discuss these on the next working group call.

What outcomes are important to you and your organization or customers?

[gffletch]

Mechanism to enable SSO login/access compliant with NIST levels (IAL and AAL)

[2MarkMaguire]

More streamlined user lifecycle management and entitlement management

[rajnadimpalli]

1. OIDC profiles for enterprise first party applications
2. Managing and securing identities not tied to individual users (machine identities)
3. Continuous authentication and authorization
4. Streamlined vendor/contractor identity management (onboarding, offboarding etc)
5. Employee Identity verification and proofing
6. Phishing resistant identity onboarding
7. Phishing resistant authentication and authenticator enrollment
8. Data minimization (guidelines for collection and transmission of PII data in identity assertions)

[mcguinness]

• Enable enterprises to ensure apps that connect to the enterprise provide a required set of security controls for authentication, session management, and lifecycle management, zero-trust and least privilege and are "secure by default" before they authorize users to access the application
  • Enable self-service apps to securely connect to the enterprise without the app being fully managed and the enterprise having a full oauth relationship with the app (only the app has a relationship with enterprise).
  • Enable apps to grow enterprise maturity capabilities by incrementally adopting profiles and security controls that have clear value propositions to the enterprise without needing to replace legacy implementations and have long migration cycles (doesn't require replacing SAML to gain maturity)
• Reduce interoperability overhead and testing for app builders to connect to enterprises with different IAM vendors for authentication, session management, and lifecycle management, zero-trust and least privilege
  • Enables apps to implement fine-grained authorization and zero-trust policies based on authentication, identity verification, and device context provided by the enterprise and and remediate step-up/additional verification back to the enterprise
  • Provide security best practice and and interoperability requirements for multi-tenant apps and multi-tenant IdPs especially for account linking/binding across protocols and tokens
  • Provide security best practice and and interoperability requirements for non-human identities for workloads/services/automation.
• Enable enterprises to have a control plane for change management and lifecycle of identities (user, groups, services/workloads/clients), credentials, trusts/federations, privileges, sessions, policy, oauth clients+grants, and security control configuration for managed applications
  • Enable automated key/credential rollover for enterprises to respond to security threats/breach to ensure breached credentials are no longer valid for apps
  • Enable session and token revocation for principals to ensure all access has been revoked
  • Reduce the enterprise overhead of managing a large ecosystem of connected applications where apps connect to each other and have their own authorization server creating security silos
• Provide interoperable patterns for time based session privileges (JIT) to reduce standing privileges and enable zero-trust access to enterprise resources

[ttripp]

As a B2B SaaS vendor (HPE GreenLake), our goal is to simplify support for our customers by addressing a basic set of common use cases. Additionally, we want to establish a unified integration paradigm for our ecosystem of downstream apps that connect to HPE GreenLake.

We believe it is crucial to enable "table stakes" use cases easily while progressively enhancing security and compliance across different aspects of the IPSIE profile. Given our experience with multiple apps, we understand that securing business approval for large-scale projects can be challenging. However, breaking these projects into smaller, manageable increments makes it easier to achieve incremental compliance.

Table Stakes (in order of priority):

1. Single Sign-On Profile: Prefer OIDC for ease of key management, but also support SAML for legacy systems.
2. Single Logout: Provide a consistent and reliable logout experience across all connected apps.
3. Session Revocation: Enable immediate session termination to enhance security.
4. User Lifecycle Management: Ensure it integrates seamlessly with SSO JIT and user groups.
   • Note: SCIM protocol may face scalability issues with asynchronous operations and large user groups

Extended Capabilities:

1. Re-MFA on Demand: Allow apps to request re-MFA from upstream IDP to support step-up authentication flows.
2. Risk Signal Sharing and Consumption: Enable SaaS apps to share risk-related information with upstream IDPs/vendors and receive risk signals without requiring the SaaS app to actually do the delta calculations / risk calculations. For example, this includes changes in IP address with the external vendor handling the calculations like velocity, etc and responding with risk level.
3. Entitlements: Manage and enforce user entitlements effectively. This will be particularly challenging as authorization varies greatly between existing apps.

API Security:

• API Token Security Profiles: Standardize recommended OAuth configurations to reduce complexity and enhance security.

[deansaxe]

@ttripp Note that the SCIM WG in IETF is working on multiple items to address scalability, including cursor based pagination, delta queries, and SCIM profile for Security Event Tokens. Each of these should address some part of the scalability issues in the current SCIM protocol set. https://datatracker.ietf.org/group/scim/documents/

Having said that, SCIM is not the only way to provision/deprovision users. It is an option that may be used.

[aaronpk]

Things related to SSO

• Support IdP-initiated login (enabling the user to start at the IdP dashboard)
• Enforce security of the flow at the IdP (rather than assuming a correct RP implementation)

[joninusa]

Exchange of location awareness for users behind a cloud proxy or secure service edge.(SSE) This could replace using X-Forwarded-For and will enable IDP identity protection mechanisms.

[lee-tschetter-cerby]

@ttripp as a PM at a B2B SaaS vendor I agree with you. What is your perspective on signals upstream from you vs downstream? Is it your responsibility to aggregrate and normalize signals before passing them downstream, or are you just repeating the signals and letting the downstream systems make their own decisions?

[ttripp]

@joninusa This would be very helpful to me. We have so many layers of API Gateways, etc that the x-forwarded-for is untrustworthy, including for web application firewalls. Not location awareness, but maybe also JA3/JA4+ fingerprinting should be included in the framework.

[jischr]

I'm interested in this use case:

For SSO flows, an OP might want/need to delegate authn to a another OP (i believe auth0 calls this a connection), whether for the first factor of auth or for a higher level.

In these cases, the client may want to specify which provider the OP should delegate auth to. I'd like to prescript how this could be specified.

[aaronpk]

A higher-level outcome, related to the discussion on IPSIE "levels":

I want to be able to have a label such as "IPSIE Level 1" and know that two products with that label are guaranteed to interoperate for the given features defined in that level, without special-casing for individual providers.

[dhs-BI]

@joninusa This would be very helpful to me. We have so many layers of API Gateways, etc that the x-forwarded-for is untrustworthy, including for web application firewalls. Not location awareness, but maybe also JA3/JA4+ fingerprinting should be included in the framework.

@ttripp can you help explain why you think the fingerprinting belongs in IPSIE? I understand the usefulness of the data, but I'm trying to understand why IPSIE should take a stance on this specific signal.

[topperge]

Mechanism to enable SSO login/access compliant with NIST levels (IAL and AAL)

It will have to be NIST level by revision number as well, i.e. Rev 3 vs. Rev 4

I've also been seeing government orgs (like login.gov) needing to implement vectors of trust on top of the IAL levels to get the levels of precision (wrong word, I'm tired) across agencies.

[topperge]

I would highly like to see the ability from day 1 for each service to indicate what Entity Categories they support as part of the service, similar to what REFEDS has defined: https://wiki.refeds.org/display/ENT/Entity-Categories+Home
Or what has been defined in the US Intelligence community: https://www.dni.gov/index.php/who-we-are/organizations/ic-cio/ic-technical-specifications/unified-identity-attribute-set
Or with NATO ÅCP 240
This should allow different industry verticals to define their attribute bundles and have defined values for each of them. This would prevent the manual remapping of attributes and values each time an IdP is added to a federation.

Additionally, I would like to see a functional requirement that severs and clients must support 2 or more concurrent signing and encryption certificates.

Both of these would highly reduce operational burdens across the board.

[sbroddy]

Additionally, I would like to see a functional requirement that severs and clients must support 2 or more concurrent signing and encryption certificates.

You'd get a strong second from me on this. Flag day certificate rotations become impossible once you've reached a certain scale. And the lack of support for multiple certs is both an operational impediment and a security risk/vuln.

[dhs-BI]

Standardized mechanism, perhaps based on OIDC, to communicate the results of an identity verification or identity proofing event. This would allow for drop-in integration of ID verification/proofing vendors into enterprise systems to enable onboarding/recovery flows.

[aaronpk]

Standardized mechanism, perhaps based on OIDC, to communicate the results of an identity verification or identity proofing event. This would allow for drop-in integration of ID verification/proofing vendors into enterprise systems to enable onboarding/recovery flows.

+1 from me on this! There's already an OpenID spec for this too! https://openid.net/wg/ekyc-ida/specifications/

[sbroddy]

IdP support of being able to assert IAL similar or equivalent to as documented and adopted in the R&E space as part of the Assurance Framework. RAF

[sbroddy]

Re-MFA on Demand: Allow apps to request re-MFA from upstream IDP to support step-up authentication flows.

This should already be possible in SAML. At least the pieces should be there. whether or not RPs support it is another question.

RP invalidates session, sends AuthN Request to IdP with forceAuthN set. Whether or not the IdP respects it is another discussion. Most of the non-commercial IdPs in use in my ecosystem DO support it.

[dhs-BI]

Re-MFA on Demand: Allow apps to request re-MFA from upstream IDP to support step-up authentication flows.

This should already be possible in SAML. At least the pieces should be there. whether or not RPs support it is another question.

In the OIDC realm, this is RFC9470.

[mcguinness]

The P0 interoperability step-up MFA gap is around ACRs as previously discussed in https://github.com/pamelatech/ACRminprofile/blob/main/MinACRProfile-0.2.md.

Is there a reason we are not brining this draft into the WG?

[aaronpk]

If I remember correctly, there was something about it Pam wanted to change still. But that draft in particular is generic enough to OIDC that it should probably live in the A/B Connect WG rather than the IPSIE WG, then we can reference it in the IPSIE OIDC profile.

[mdorey]

One thought I had for an outcome for IPSIE. I'd like to see IPSIE provide guidance on authentication and authorization recommendations for SCIM. While SCIM is highly flexible the lack of prescribed recommendations leave a gap in standardization that results in inconsistency across the industry. So recommendations around the primary authentication mechanism (i.e. OAuth) and discouraged authentication methods (basic), authorization recommendations (use of RBAC, use of standardized scopes) and possibly even deployment recommendations (rate limiting).