# SCIM working group 2023-11-09 {#scim-working-group-2023-11-09} ## Agenda {#agenda} Agenda presentation: No changes proposed to the agenda ## SCIM use cases {#scim-use-cases} 3 new challenges: 1. Reconciliation: How to let a client know that a SCIM object has changed on the server 2. HR applications: Who is authoritative for a resource attribute? 3. Extra RA for RO: Attributes can come from different sources How to use the existing model to address the 3 challenges? 2 options: 1. Both IdM and SaaS application are SCIM server and client 2. keep the same roles, client needs to do GET, server returns delta Discussion: George Fletcher: How does the server know who is authoritative for the attribute? Paulo: There needs to be a policy agreement between both ("authoritative" is outside the scope of the protocol). George: notes that outside protocol is confusing Dean Saxe: Authorization is not in scope and would require recharter Phillip Hunt: The receiver is the one that deals with access control and has its own authority to decide. Authoritative application signals events. George: Philip's version will work with option 1 as it is up to the server to decide if it will accept the change or not. SCIM server decides what events it will accept. Paulo clarifies: not option 1, it's option 3 where server signals to the client of an update for the field....so option 3 is missing George: does not need to be pub/sub, could be option 1. IDM receiving message should decide if it wants to accept the update or not. Pamela: Ack Danny: Simpler to have the IdM managed logic vs putting the burden on 100s of SaaS application vendors since everybody's business logic and flow of data is going to be different Next steps: Nancy's question to the group: Who has reviewed the draft? Poll: 5 Yes, 11 No, 21 total Volunteers to review the draft: Dean Saxe, Anjali, Hans-Jörg will review Those who have reviewed: is this a good starting base? ## SCIM events update {#scim-events-update} Nancy recuses herself as chair Set up a new IANA sub registry for events Asynchronous event delivery Asynchronous requests: Header Prefer: respond-async per RFC 7240 Async bulk requests: how to handle multiple operations? Event request/response shown Status and next steps: Implementations Draft 4 - minor wording fix to IANA (from mailing list) Next step: working group last call? Who has reviewed the latest version of the draft? Poll: Yes: 4, No: 11 Call for more reviewers Volunteers to review the draft: Eliot Lear, Paulo, Pamela Roman: Positive affirmation helps, please let us know if you've reviewed it and no changes required Jennifer Schreiber: We need to spend a little more time with the async bulk since there are a few loose ends and is not comfortable moving forward yet. Chair: pls put on mailing list, or we can discuss now Jennifer: concerns using `-1` at the end of the `txn` to makr different transactions. could be confusing to use - as separater. `#` could be better. Phillip Hunt: Agree with the concern. Will look into `#` Jennifer: Would be good to know how many transactions are expected for the bulk grouping. How does the receiver know that it is done? Phillip: The receiver would know based on the number of transactions sent. Does not want to overload the protocol. Also, implementers are free to optimize the order (from the original SCIM protocol) and the time of the event is not in sequence but the counters are in sequence. That is how you would detect that it is out of sequence. Jennifer: My concern is in case no response came back for a transaction. Phillip: We could put it in the text that the number of events returned should be equal to the number of operations submitted. The Bulk API requires a response for all transactions, even errors. Chair: Volunteers need to wait to review until the next version of the draft is out (draft-4). 1. publish draft 4 2. Get reviews 3. Feedback on the mailing list 4. Assuming no big issues, working group last call on the list ## SCIM devices {#scim-devices} Eliot Lear draft-01 is out ### Recap: {#recap} This draft turns SCIM around. Device provider is the SCIM client, enterprise is the SCIM server. Zigbee, BLE, Wi-Fi DDP described Interest from FIDO. Probably wired DPP as well. Expected to see from Matter and enOcean. relevant to NIPC draft Changes since IETF-117 1. added a `mobility` attribute 2. Non-normative corrections to the openapi model 3. client-token -> clientToken 4. Some folding changes in examples 5. Implementation: github.com/iot-onboarding/tiedie Issues remaining: 1. non-IoT device provisioning - need a proposal: Danny!? 2. versioning (per model, per object): no strong view from authors, might make sense to use object level versioning, as changes may not be frequent 3. Security considerations: currently still TBD. some issues that need to be described: Some device credentials could be sent in certain use case. Encryption over the top might be very important. 4. IANA considerations: also still open. 5. Extensibility: Extensibility needs to be furhter detailed in the draft. For example adding LoRA. 6. Any additional models Timeline and location: Aim towards last call in spring Eliot's ask to the chairs: Where should the draft reside on GitHub? Chair will send Eliot the link to SCIM GitHub org Discussions: Danny Zollner: Danny will provide feedback Dean Saxe: shared interest as aligned with FIDO. SCIM can be used to provision FIDO keys. and assign Eliot: Working with Geoff Cooper. We have realized the the scim model provides a dispatch function which tells which is the next process to go to based on the device. For FIDO, there might be several dispatch functions, (e.g, wired, wireless). Dean: In addition to FDO use case, thinking about hardware keys and pre-provisioning those and assign to users. effectively use a mechanism to pre-provision that credential and have a way to unlock the hardware key that is probably out of scope for SCIM. Eliot: Relevant to access control in SCIM Pamela Dingle: Makes a ton of sense. One concern: device is a very generic term. There could be different device types. Is there a more specific name you can give to this device type? Eliot: Since this is about network devices, we could call it something like network devices, IoT device, network provisioning information Bart: Would be interesting to see if we can actually have a generic device category that covers multiple use cases. Next steps: Move github repo to SCIM org ## SCIM delta query {#scim-delta-query} 2 options: 1) Time based approach 2) Delta database Goal: Enable incremental retrieval of resources Identify deltas Provide a new interface for getting incremental updates to SCIM resources. This API provides changes to be retrieved vs a time reference Requirements: 1. resources modified since a specific point can be returned by query 2. current state of resources returned 3. convey that a previously existing resource was deleted 4. convey changes to group memberships 5. performant How does it work? step 1: obtain the first delta token: GET /Users?deltaQuery The response has a nextDeltaToken on the last page of the full scan response, which can be used for subsequent delta requests. Step 2: Use the deltaToken (delta scan) Client can decide the interval at which to send the delta scan Server will return only the resources that have been modified since the last delta query (when deltatoken was returned) Changes to Resource representation: Newly created and updated resources use their standard representation and their current state is returned Deleted instances must return common attribute id and complex attribute meta with sub isDeleted Pagination: In the delta scan query, there is a `nextCursor` and the last page has the `nextDeltaToken`. Subsequent pages are fetched using the `cursor` query parameter (from `nextCursor`). Considerations: 1. No locking resources when the delta query is performed 2. New items can be added or can be removed while paginating through the response. 3. The delta query must guarantee that the records are not skipped Service provider configuration: /ServiceProviderConfig to denote if they support this API or not Group memberships Get groups that have members added or deleted through deltaQuery With large sets of members this appraoch becomes difficult Draft has been published in SCIM WG github Discussion: Chair: Pls post draft on datatracker, and solicit feedback on the SCIM mailing list Danny Zollner: Complex topic. This is a foundation to start discussion. Feedback pls! Pamela Dingle: Spec describes you need to do a full scan query to get the first token. What if the collection is too large to do a full-scan query? Is there a way to get the reference point in another way? Anjali: Not sure if we can because the reference point is what the server has returned. The assumption is that before the point, the two systems have the data. Dean Saxe: Can you ask for a token as of now, if you already have the data? Danny: Whether the delta query parameter needs to be tied to the initial sync or it can be issued at a point in time. We can look at the feedback and figure out the right direction? Paulo Correia: Could we get the token in the initial sync? Anjali: Yes, once the initial sync is done, the token can be requested, and we do not return the full set of resources. Other option is if you already have the data in both systems and not sure if it is in sync. You do full scan and request token. Paulo: Token could be given immediately as part of the sync. Anjali: How does the server know that after a record, the sync is complete? Doing the GET on a resource with a delta query sets up the baseline in getting the token. Paulo: so until we receive the token from the server, there cannot be any change? Anjali: Client drives when to do the sync. Server can create a changelog at any time. Paulo: Inconistencies? It will take a long time to do the sync and then get the token. Anjali: We are not proposing locking because that will not scale. The server will only track changes after toekn gets returned, so there will not be inconsistencies Paulo to discuss offline to work it out. Mike Kiser: Will create a PR to contribute to the language on the approach on doing delta queries often if they are going to take forever. Question: Is it fair ot say that each token is sequential? Anjali: It is not stated but it will be. Mike: Is token client specific? Anjali: It is not client specific. it is global so the server doesn't keep track of the token it sent to which client. Mike: Responsibility of token use is on the client Anjali: correct Dean Saxe: Specifies restful API's between client and server. Does not specify client or server behavior. This is outside of the WG realm. Next steps: publish to data tracker and update on the mailing list. ## other business {#other-business} No other business