# IETF 116 March 28, 2023 {#ietf-116-march-28-2023} # SCIM {#scim} ### Chairs: Nancy Cam-Winget, Aaron Parecki {#chairs-nancy-cam-winget-aaron-parecki} ### Notetakers: Dean H. Saxe, Danny Zollner {#notetakers-dean-h-saxe-danny-zollner} ### Agenda Bash & Logistics: chairs {#agenda-bash--logistics-chairs} ### Use Cases document update : Pamela Dingle and Paulo Correia {#use-cases-document-update--pamela-dingle-and-paulo-correia} * No slides * Pam and Paulo are looking for feedback on the SCIM use cases from implementers. * The current doc is in a private github repo, they will share it to the WG after the meeting. * They are introducing some new terminology regarding actors/functions in SCIM such as resource owner, resource creator, etc. These are used to descrive the roles/constructs for implementation of SCIM. * * Moving away from users/groups and focusing on resource objects to accomodate the new types of object proposed for use in SCIM * They are describing attributes as being read only, read write, etc. to accomodate different roles in the use cases * Triggers and notifications for instruction to update, create, delete resources * Previous use cases were 1:1 relationships of client to server, but this doesn't match the reality of actual deployments * * client-server is a common pattern, but not the only one * * they are building use cases upon each other sequentially in the doc * these new use cases allow for services such as slack or WebEx to be in control of specific attributes associated with a user * Where Paulo and Pam are struggling is how to map this to the RFCs that exist today * * looking for feedback to bring more clarity to the use cases and how they are implemented with the existing RFCs * Nancy asks that the link is posted to the mailing list and/or github to receive feedback ### SCIM Events: Phil Hunt {#scim-events-phil-hunt} https://datatracker.ietf.org/doc/draft-ietf-scim-events/ * Update on SCIM events * Draft now has security & privacy sections and IANA section * Use case data was moved to the appendix * Spec was modified to comply with OpenID Foundation Shared Signals Framework * * this opens up some flexibility to use different subject idnetifiers such as username or email address * There are 4 clsses of events * * Feed control events as done in the SSF * * Provisioning events that mimic SCIM operations * * Signaling, such as password reset events * * Async events to confirm long running SCIM operations * Section 3 discusses how to secure events as they are transmitted on the wire to provide optionality * Added clarification on how recovery events happen (e.g. messages dropped) * * SECEVENTS is focused on short term recovery by the issuer of the event * * Receivers are responsible for recovery after an event has been acked * IANA issue has been raised - there is no registry for secevents * * the SECEVENTS group never established a registry, trying to do so now may be controversial * * We may be able to register this under SCIM * * Phil suggests setting up a namespace under SCIM * Elliot Lear - What would the IANA model be for a SCIM registry? * * Phil does not think there is a great amount of value in using an IANA registry * ### Cursor-based Pagination of SCIM Resources : Dean Saxe, Anjali Sehgal, and Danny Zollner {#cursor-based-pagination-of-scim-resources--dean-saxe-anjali-sehgal-and-danny-zollner} https://datatracker.ietf.org/doc/draft-ietf-scim-cursor-pagination/ * Matt Peterson stepping back from draft * Danny Zollner, Dean H. Saxe, Anjali Sehgal and David Brossard to take over * Addressing feedback during adoption call. * Potential for denial of service, in context of response snapshot from service provider, hacker can keep those alive to exhaust server memory. Similarly, concern on statefulness. Implementors could lock memory brining security issue as threat actor could lock resources to block user deactivation (e.g. termintation). Responses: pagination is not expected to be stateful, no normative language. * Additional requirement of change detection/delta query while not a requirement were added but not a requirement. * Differences between index vs. cursor based pagination is called out in draft. * Proposed text presented and not added in the draft. * Philip: points that paging doesn't allow data to change so the text proposed seems contradictory. * Anjali: text was to be alternate to index based pagination, not allowing sources to change. Cursor, if underlying source change (index allows skipping or duplicating records) so behavior is different. Underlying databases do not support index based, so translation layer would be required adding complexity. * Philip: not clear that it would be to reconcile two record * Joris Baum: for cursor needs to save state of index? something is needed (statefulness) to ensure data of the indexes can be stateless but the result set should be stateful. That needs to be clarified. * Danny: agrees text needs to be clarified. Attribute value can be at a point in time vs. snapshot. * Dean: document intro states intent is to bring alternative to index vs. synchronizing across client and server. * Aaron: result from discussion is that clarification on the proposed text is required. * Next steps: new version will come with updates as well as security issues as discussed here and from the maillist. Including someone frmo HTTPDir review of draft. ### Device Schema Extensions to the SCIM Model : Eliot Lear {#device-schema-extensions-to-the-scim-model--eliot-lear} https://datatracker.ietf.org/doc/draft-shahzad-scim-device-model/ * Update to the draft on SCIM devices. * Goal - automate all/most provisioning of devices with CRUD ops * use a set of SCIM extensions for device provisioning and an externsion to permit device manager endpoint registration * Basic model - provisioning a device for network access * * heavily dependent upon the type of device how the network access is provisioned * * extension schemas define the device control mechanisms - HTTP or MQTT * * extension schema also defines device telemetry (e.g. MQTT) and then endpoint to collect the telemetry * Multiple new schemas * * Core device - display name, adminState, etc * * BLE extension - authentication mechanisms and version support info to onboard the device * * WiFi Alliance EasyConnect - onboarding WiFi access through trusted introduction * * Zigbee - similar to BLE * * Endpoint Apps - provides for authorization tokens to enable devices to connect to the gateway (SCIM server in this use case) * * Mattr work is pending * Status - working on open source implementation, timing TBD. This is primarily client code focused on device provisioning SDK * Feedback received on v0 was primarily on schema format * Specs are maturing - considering working group adoption * * Need volunteers to review to prep for a call for adotpion * * Nancy states that we can do a call for adoption starting next week, needs at least 3 people to chime in for readiness of the draft * *