SCIM working group 2023-11-09

Agenda

Agenda presentation: No changes proposed to the agenda

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

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 <uuid>-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

Eliot Lear

draft-01 is out

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

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

No other business