What are the "task forces" that need to be set up for IPSIE? How do they operate?

[dhs-BI]

On the November 12 2024 call, we discussed setting up task forces to work across different subsets of the IPSIE profiles.

1. What are the different task forces?
2. How do we coordinate the work to ensure the subgroups can work independently without producing contradictory guidance?

[dhs-BI]

1. Following yesterday's call, I suggest that the task forces are generally broken down based upon specific outcomes. The following list is a starting point:
   a. Single Sign On (e.g. OIDC/SAML)
   b. Application authorization (OAuth)
   c. User synchronization (e.g. SCIM & non-SCIM mechanisms)
   d. Signal sharing (e.g. Shared Signals Framework & non-SSF mechanisms such as API calls, message queues, etc.)
   e. End user authentication

2. As suggested on yesterday's call, Karl McGuinness is going to put together a straw man to identify the work that is cross-cutting. As this comes to fruition, we should use this as guidance to the task forces. Task forces with cross-cutting concerns must coordinate to ensure their work streams remain aligned. Conflicts should be resolved between the task forces with unresolved conflicts being raised to the larger IPSIE WG for discussion and resolution.

[Tom-MITRE]

"Orchestration taskforce"

• keeps track aggregated discovery and registration metadata, service endpoints, and cross-protocol flows within the use cases
• keeps track of aggregated logging and events from SIEM/Security Operations Center perspective

"Threat"

• Do the cross-protocol flows expose new vulnerabilities not already addressed by protocol-specific threat models?

[kennchong]

At a high level, let's agree on 1 inital use case that the taskforce groups will solve. Here's a proposal:

1. As a new user, I want to be onboarded to the IdP for the first time, securely enroll for my first credentials, and use that to sign-on to my first app.

All 5 of Dean's taskforce should have an opinion on how to make this use-case secure from day 0.

[dhs-BI]

@kennchong Thank you for the use case. I suggest we come up with a few more use cases so that the group can make progress in parallel. (@dhs-BI edited this sentence for clarity.)

With my chair hat off, I'll offer a few examples:

• As an enterprise, I want to be able to onboard new SaaS apps with a known set of secure by default configuration options when using federation.
• As an enterprise, I want SaaS apps to be able to enforce authentication requirements (e.g. phishing resistant authentication, recency of authentication events), returning users to the enterprise IdP for remediation when necessary.
• As an enterprise, I want to be able to manage user lifecycle events (join/move/leave) across a set of SaaS applications to reduce licensing costs and ensure access is granted/removed in a timely manner. This may include JIT provisioning and/or pre-provisioning of users in downstream applications.
• As an enterprise security manager, I want to ensure that a user with risky signals (e.g. impossible travel, account takeover, account recovery, malware present on device) can be excluded from specific operations or have their sessions revoked until the user/device are in a healthy state.

This is just a quick list off the top of my head without any implied prioritization.

Chair hat back on: I encourage the group to continue writing use cases to help us find the "right" task forces and interconnections between them.

[victorjunlu]

As an enterprise, I want AI-driven search to unify knowledge access while ensuring secure integration, advanced authentication, automated user management, and robust tracking of cross-system interactions to enhance security and productivity.

[leleabhinav]

Fingerprinting

There should be a framework on defining how a user/machine is identified. (JA3/JA4, Browser signatures).

Mobile

There should be a different emphasis on how login flows for mobile are kept secure. Mobile is uniquely placed in terms of how secrets are managed. While the client_id is not associated with a secret, each app has access to a vaulted secret store which is present on the mobile device.

With OIDC, to add more security PKCE is required, but often the flow is much complex vs. a full browser. Mobile applications needs to authenticate inside a webview, which has constrained capabilities vs a full browser. Enterprises define their own custom way of handing off artifacts between a full browser on the mobile OS to the app or webview (and try to circumvent restrictions). There should be a standard way in which the flow is handed over to a mobile in the different contexts. ( for example - React Native layer and webviews). Bottom line is that we should provide guidelines and/or specify how all IPSIE flows relate to mobile.

[topperge]

Here's an initial list of categories, user stories, and actors I'd suggest. Task forces by category with category leaders in a "master council" style to bring things together across the categories.

Do we also want to define the actors in the ecosystem that we want to think about their experiences within each task force?

1. Employee
2. Application Developer
3. Enterprise Admin
4. Security Officer
5. Auditor
6. Compliance Officer
7. DevOps Engineer
8. Federated User
9. Partner Organization
10. System/Resource/Application Owner
11. Machine Service
12. Tenant Admin

---

1. Single Sign-On (SSO)

1. As an employee, I want to log in to all enterprise applications using a single set of credentials to simplify access and reduce password fatigue.
2. As an application developer, I need to implement a standardized SSO profile to ensure interoperability with enterprise identity providers.
3. As an enterprise admin, I want to enforce secure defaults (e.g., MFA on SSO) for all integrated applications to reduce the risk of credential theft.
4. As an end user, I want to be redirected seamlessly between SSO-enabled applications without being prompted to log in multiple times.
5. As a compliance officer, I need logging and traceability of SSO interactions across all applications for auditing purposes.
6. As a federated user, I want my SSO experience to work consistently across partner organizations using different implementations.
7. As a system owner, I need standardized session timeout policies for SSO to align with enterprise security requirements.
8. As a developer, I want clear documentation and examples to integrate SSO in my application using secure defaults.
9. As an admin, I want automated metadata discovery for SSO configurations to reduce manual errors during setup.
10. As a DevOps engineer, I want to automate SSO provisioning and configuration via APIs to align with CI/CD practices.

---

2. User Lifecycle Management

1. As an HR system admin, I want new employee accounts to be automatically provisioned across all enterprise applications upon hire.
2. As a compliance officer, I want to ensure terminated employees’ accounts are deactivated immediately across all systems.
3. As a team manager, I want to request additional access for my team members directly through an IAM portal.
4. As an employee, I want to update my name or contact details in one place and have it reflected across all connected applications.
5. As a system admin, I need clear visibility into orphaned accounts and the ability to clean them up automatically.
6. As an auditor, I need detailed logs of user account creation, updates, and deletions for compliance reviews.
7. As a new employee, I want my onboarding to include automatic provisioning of accounts with appropriate access rights for my role.
8. As a system owner, I want the ability to suspend user accounts temporarily without removing access configurations.
9. As a security officer, I need to enforce strict identity proofing before account activation to reduce insider threats.
10. As a developer, I need APIs for managing user lifecycles to align with enterprise identity policies and standards.

---

3. Entitlements

1. As an employee, I want to see all the applications I have access to and the permissions granted to me in one place.
2. As a security officer, I need to implement fine-grained entitlements based on user roles and attributes.
3. As an auditor, I need to generate reports showing entitlement assignments across all enterprise applications for compliance.
4. As a manager, I want to review and approve or deny entitlement requests from my team members.
5. As a system owner, I want to define default entitlements for new users based on department or job function.
6. As an application owner, I want a centralized way to manage and update entitlements across multiple systems.
7. As a developer, I need APIs for querying and modifying entitlements in real-time based on changing business requirements.
8. As a compliance officer, I need regular reviews of entitlements to ensure they comply with security policies.
9. As a DevOps engineer, I want entitlements tied to service accounts for automated workflows to ensure least-privilege access.
10. As a security officer, I need dynamic entitlements that adapt based on contextual signals like location or device trustworthiness.

---

4. Risk Signal Sharing

1. As a security officer, I want risk signals (e.g., unusual login locations) shared between applications to make access decisions more dynamic.
2. As an application owner, I need APIs to consume and respond to shared risk signals from the enterprise security framework.
3. As a compliance officer, I want visibility into how risk signals are factored into access decisions for auditing purposes.
4. As an admin, I need automated workflows to suspend or revoke access based on high-risk signals.
5. As a developer, I want guidelines on integrating shared risk signals into custom applications without compromising performance.
6. As an employee, I want to receive notifications if my account triggers a risk signal so I can take corrective action.
7. As a system owner, I want to enforce step-up authentication based on contextual risk signals like device reputation.
8. As a security officer, I need real-time dashboards showing aggregated risk signals across all enterprise systems.
9. As an admin, I want configurable thresholds for triggering actions based on risk signals.
10. As a partner organization, I need interoperability standards to share risk signals securely across federated environments.

---

5. Logout and Token Revocation

1. As an end user, I want to log out from all applications at once to ensure my session is completely terminated.
2. As a developer, I need clear guidelines for implementing logout functionality that works consistently across applications.
3. As a security officer, I want token revocation to propagate immediately across all systems to prevent unauthorized access.
4. As an admin, I want APIs for batch token revocation during incident response scenarios.
5. As a compliance officer, I need logs of logout and token revocation events for auditing and security reviews.
6. As a developer, I want tools to test logout and token revocation flows during integration.
7. As a security officer, I need logout processes to be seamless and user-friendly to encourage proper usage.
8. As an enterprise admin, I want single logout (SLO) to work across federated applications without leaving residual sessions.
9. As a system owner, I need to ensure token revocation mechanisms comply with the organization’s risk management policies.
10. As a developer, I want example code and SDKs for logout and token revocation to simplify implementation.

---

6. Developer Experience

1. As a developer, I want well-documented SDKs in multiple languages to integrate authentication and authorization quickly.
2. As a product owner, I want a self-service developer portal where I can register and manage my applications with the IAM system.
3. As a developer, I need clear error reporting and debugging tools to troubleshoot integration problems efficiently.
4. As an admin, I want sandbox environments to test IAM integrations without affecting production systems.
5. As a DevOps engineer, I want CI/CD pipelines to deploy identity configurations automatically alongside my application code.
6. As a developer, I want to dynamically register my application with the identity provider to avoid manual configuration steps.
7. As a compliance officer, I need APIs to validate that all applications meet organizational identity security standards.
8. As a developer, I want sample code repositories for common use cases like login, token exchange, and access delegation.
9. As a team lead, I need a quick-start guide to onboard new developers onto our identity integrations within hours.
10. As a developer, I want API throttling and rate-limit documentation to design my application for scalability.

---

7. Identity Federation

1. As an enterprise admin, I want to configure SAML-based federation to allow employees to log in to partner systems without creating new accounts.
2. As a partner organization, I want secure SCIM provisioning to ensure my users are automatically synced with the enterprise directory.
3. As a system owner, I want to enable just-in-time (JIT) user provisioning for users logging in through federated IdPs.
4. As a developer, I need APIs for automated federation metadata updates to reduce manual configuration errors.
5. As a federated user, I want consistent experiences regardless of the federated provider I use to authenticate.
6. As a security officer, I need to enforce strong encryption on all SAML assertions to secure user identity data.
7. As a multi-cloud admin, I want to establish trust relationships between clouds for seamless cross-environment federation.
8. As an auditor, I need a report of all active federation agreements for compliance and security reviews.
9. As a tenant admin, I want to map federated user attributes to my local directory structure to ensure proper access.
10. As a developer, I want federation error diagnostics to debug SAML or OIDC integration issues effectively.

---

8. Authorization

1. As an application owner, I want to define fine-grained access controls based on user attributes, such as department or clearance level.
2. As a developer, I need role-based access control (RBAC) APIs to manage permissions programmatically.
3. As an admin, I want a policy engine that supports ABAC so I can create access rules based on dynamic user attributes.
4. As a user, I want to grant limited-time access to external contractors to ensure temporary permissions.
5. As a security officer, I need real-time token introspection to validate active sessions and revoke compromised tokens.
6. As a compliance manager, I want a consolidated view of all user permissions across systems for governance reviews.
7. As a machine service, I want to request a scoped token to access only the resources I need without excessive permissions.
8. As an enterprise user, I need self-service access request workflows to minimize dependency on IT for permissions.
9. As a resource owner, I want to delegate access to specific resources, such as files or data sets, to a colleague or external party.
10. As an admin, I need tools to create and enforce least-privilege access policies across all applications.

[dhs-BI]

Keeping this open right now while we work on v1 scope. My hope is that the v1 scope will guide us to the answer on the task forces for our near term work.