**Session Date/Time:** 23 Mar 2022 13:30

# scim

## Summary

The SCIM Working Group session focused on the progress of updating existing specifications and exploring new areas. Key discussions revolved around modernizing the SCIM use cases and concepts document (RFC 7642), defining a path forward for SCIM protocol and schema updates (SCIM 2.0 vs. 3.0), and the applicability of Security Event Tokens (SET) and Shared Signals and Events (SSE) for SCIM event-based communication. The group reached consensus on incorporating IoT/device use cases into the main use cases draft and for the protocol/schema editors to prepare a preliminary draft for further discussion and adoption.

## Key Discussion Points

*   **SCIM Use Cases and Concepts Document Update (Pam Dingle)**
    *   **Goal**: Update RFC 7642 to better serve as an overview and guide for modern SCIM implementers, explaining core concepts and use cases not fully covered in the original document.
    *   **Proposed Outline**:
        *   **Definitions**: User management, group management, provisioning.
        *   **Concepts**: Start of authority (authoritative source for attributes/accounts), data directionality (master/slave, bi-directional sharing), Just-In-Time (JIT) provisioning, schema and resource types, mutability and uniqueness, identifiers and primary keys (e.g., `externalId`), API security, hard/soft deletion, privilege elevation.
        *   **Feedback on Concepts**: General agreement on the proposed concepts. Suggestion to consider "connection directionality" beyond RESTful protocols (e.g., gRPC, WebSockets) to account for reverse connectivity.
        *   **Implementation Use Cases**: Negotiating schema, search and query, object synchronization, massive dataset maintenance (pagination, bootstrapping, bulk operations, reconciliation).
        *   **Feedback on Use Cases**:
            *   Need to address sensitive data protection (e.g., URLs to photos).
            *   Consider more business-oriented "self-service" scenarios.
            *   Incorporate scenarios for change of ownership on devices and managing long-term authority changes for trust relationships, especially relevant in IoT.
*   **IoT/Device Use Cases (Elliot Lear)**
    *   **Distinction**: Device identities differ from user identities (e.g., light bulb lacks user interface).
    *   **Onboarding Challenges**: Multiple onboarding standards (Wi-Fi DPP, 802.1AR, BLE OOB, FIDO FDO) require automated, seamless credential transfer. This necessitates schema design that supports various key materials (public keys, vouchers).
    *   **SCIM Implications**: This is primarily a **schema issue** for SCIM, not an authentication issue. It requires a device hierarchy or schema within SCIM to describe device capabilities and onboarding mechanisms.
    *   **Directionality Flip**: SCIM traditionally has enterprise provisioning cloud services. For devices, the supplier may act as the SCIM client, transmitting device credentials to the enterprise (SCIM server).
    *   **Differences from Parent SCIM**:
        *   Bootstrapping credential movement is always required.
        *   Supplier as SCIM client.
        *   Clear scoping for device identities (preventing one supplier from affecting another's devices).
        *   Device attributes vary based on capabilities, impacting schema.
        *   Need for extensibility (e.g., Software Bill of Materials, device type information).
    *   **Schema Language**: JSON Schema was found to be sufficiently rich for these needs, in contrast to some challenges encountered with Swagger for a fully normalized view.
    *   **Discussion**: Confirmed that the scope should be "devices" generally, not just "IoT." The concept of a "bootstrap IDP" and a "final IDP" was introduced for devices.
*   **SCIM Protocol and Schema Updates (Danny Zolner & Janelle Allen)**
    *   **Charter Goal**: Progress SCIM 2.0 from Proposed Standard to Internet Standard.
    *   **Core Question**: Should the group "polish" SCIM 2.0 (error correction, clarity, minor enhancements) and finalize it, or should it target a new major version (2.1, 3.0) to incorporate more significant enhancements from the charter?
    *   **Chartered Enhancements**: Many proposed enhancements (e.g., clarifying `externalId` usage, account state changes, multi-value query filtering/paging) are too substantial for a 2.0-level update.
    *   **Implementation Survey**: Proposed to gauge adoption of existing SCIM 2.0 features (e.g., basic auth, passwords in core schema, `photos` as URI) to identify parts that are not widely adopted or cause interoperability issues.
    *   **"Photos" Discussion**: While described as a URI, cross-cloud security concerns, latency, and the lack of a standardized approach for servers to pull/store images lead to limited adoption.
    *   **Broader Context**: SCIM 2.0 has wide adoption in IdP-SP provisioning, raising concerns about backward-breaking changes.
    *   **Path Forward**:
        *   Option 1: Finalize 2.0 with light edits/clarifications and build out a series of extensions for new features.
        *   Option 2: Drive towards a 3.0 (vNext) that incorporates significant changes.
    *   **Guidance Needed**: Consensus sought on how light or extensive the changes should be. An issue tracker (GitHub) is being set up for managing discussions.
    *   **Relationship with Use Cases**: The scope of use case revisions (2.0 vs. vNext) will inform protocol/schema work. Some protocol/schema work can proceed in parallel with use case definition.
*   **SCIM Events Profile (Phil Hunt, presented by Nancy Cam-Winget)**
    *   **Proposal**: Profile existing Security Event Tokens (SET, RFC 8417) for use within SCIM. SETs are specialized JSON Web Tokens (JWTs) for secure, asynchronous event messages.
    *   **Distinction from SCIM Protocol**: SCIM protocol involves synchronous HTTP requests as "commands"; SETs are asynchronous, signed "statements of fact" (triggers/signals) enabling independent action by the receiver.
    *   **Importance**: Facilitates coordination of resource lifecycles across domains (e.g., user disabled in one domain leads to action in another). The receiver, with local domain knowledge, reconciles the event.
    *   **Delivery**: Leverages SET Push (RFC 8935) and SET Pull (RFC 8936) delivery specifications.
    *   **Shared Signals and Events (SSE)**: Mentioned as a framework (OpenID Foundation) that uses SET for delivery streams (e.g., Continuous Authentication and Evaluation Protocol - CAEP).
    *   **SCIM Event Use Cases**:
        *   **Domain-based Replication**: Event repeats the original SCIM protocol request with all data, allowing replicas to stay in sync.
        *   **Coordinated Provisioning**: Event contains minimal data (ID, externalId, changed attributes). Receiver marks resource as stale, then performs a SCIM GET to retrieve the current state. This avoids sharing confidential data, allows filtering attributes via access control, and supports periodic reconciliation for rapidly changing resources.
    *   **Event Claims**: Defines common claims like `toe` (time of event for reordering), `txn` (transaction ID for de-duplication), `event` (JSON structure with `id`, `externalId`, `attributes`, `data`). The JWT `sub` claim is the URI of the changed SCIM resource.
    *   **Subject Identifiers**: Recommended against using the `sec-event-subject-identifiers` draft, as SCIM's existing `id` and `externalId` mechanisms, along with resource URIs and SCIM GETs, sufficiently address identification.
    *   **Other Events**: Beyond CRUD, also includes feed events (alerting receiver of new entity), activate/deactivate events, and risk-like signals (auth method change, password reset).
    *   **Delivery Mechanisms**: Discussed bus-based systems (for internal, scalable event recovery) and point-to-point systems like SSE (for cross-domain flow control).
    *   **Scope**: Does not prescribe receiver actions; focuses on triggers.
    *   **Discussion**: Concern about using SSE (designed for observations/signals) for SCIM (which involves commands/protocol operations). Preference for a simpler event model that just signals "something happened" and lets the SCIM client figure out reconciliation, avoiding complexity of sending large data payloads within events.

## Decisions and Action Items

*   **Use Cases Document Update (Editors: Pam Dingle, Elliot Lear)**
    *   **Decision**: The outline presented by Pam Dingle in HackMD, combined with Elliot Lear's IoT/device use cases, will serve as the base content for the updated SCIM Use Cases and Concepts draft.
    *   **Action Item**: Pam Dingle and Elliot Lear to collaboratively incorporate the IoT/device use cases into the evolving use cases draft and prepare it for further working group review.
*   **Protocol and Schema Updates (Editors: Danny Zolner, Janelle Allen)**
    *   **Action Item**: Danny Zolner and Janelle Allen to prepare a first rough draft of proposed protocol and schema updates. This draft should categorize changes into what can be accomplished independently versus what reasonably depends on the revised use cases. This will form the basis for a call for adoption and further discussion on the 2.0 vs. vNext scope.
*   **SCIM Events Profile (Author: Phil Hunt)**
    *   **Action Item**: Phil Hunt to solicit more feedback on the SCIM Events profile draft via the mailing list, specifically addressing concerns raised about its applicability for SCIM commands versus signals and implementation complexity.

## Next Steps

*   **Working Group Chairs**: Schedule a virtual interim meeting in approximately six weeks to continue progress discussions.
*   **Working Group**: Provide feedback on the SCIM Events profile draft on the mailing list.
*   **Working Group**: Further discussion is needed on the overarching question of whether to finalize SCIM 2.0 with minimal changes or to transition to a SCIM 3.0 (or 2.1) to encompass more significant updates and new use cases.
*   **Working Group**: Provide an overview of existing SCIM domains and implemented use cases to inform future decisions on standard evolution.