Agenda presentation: No changes proposed to the agenda
3 new challenges:
How to use the existing model to address the 3 challenges?
2 options:
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?
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).
Eliot Lear
draft-01 is out
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
mobility attributeIssues remaining:
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
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:
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:
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.
No other business