Chairs: Aaron Parecki, Nancy Cam-Winget
Notetakers: Eliot Lear, Pamela Dingle
at 17:31 Nancy convened the meeting.
The Note Well was presented.
Code of conduct was presented.
Kathleen volunteered to be the Zulip watcher.
The wrong slide was up for the agenda.
Jen will speak to SCIM events
Eliot will give a 5 minute update on the SCIM device model
Pagination was moved to first.
The agenda was thus bashed.
Danny Zollner
Almost all feedback has been addressed.
Changes need to be reviewed and signed off.
Now we need proof of interoperability.
At least one more version coming.
Volunteers requested to help
Nancy: is anyone working on an implementation?
Angeli:
Now a -01. Lots of changes from the previous version.
New draft allowsrat qualifiers to specify which attributes should be
returned, instead of the full object
also added anti-entropy features to allow for both sides to ensure
nothing is getting missed
Introducing two new endpoints - the /.deltaToken is used to retrieve the
initial delta token. Originally it was proposed that delta query itself
would be used to get the initial data set, and the delta token would be
included as part of that initial response but to be more optimal the
scim client can use an existing endpoint to set up their baseline, and
in order to start the delta quesry there is just a separate endpoint.
The delta token retrieved from the delta token endpoint would be
provided as part of the delta request for subsequent queries.
For delta query we are using a POST pattern wihich is similar to the
.search pattern that exists in SCIM today. (shows example)
Danny:
Deeper level of detail is in draft - key things about response design:
Right now we can't see any use case where a pull model is used, a push
model is very prevalent, this seems like a blocker so we need feedback
George: in the delete case isn't there a need for metadata like the
date/time when the user was deleted?
Danny: good point, thanks we will think about it
Eliot: how does this match up with normal RESTful HTTP semantics? If I
look at delete, do you want to return anything? Could be a novice but
could we just return a 200?
Danny: in this case you aren't querying against a specific object, you
are instead querying against the root/entirety of the directory - the
delete that is returned in a delta response message gives the final
notification that the object has gone away
Eliot: is this targeting a specific resource or group?
Danny: you're not ever specifying a ggroup
Dean: I agree with George - one of the use cases is to know when
licensing should stop when querying for user resources - would be very
useful to have that data. I don't know how tracking state of deleted
users works for everyone, does that change what can be returned
Anjali: implementers will have to track some amount of data for some
amount of time to support delta query
Nancy: noted that Janelle referred to deletion state a while back,
including soft deletion status
Dean: if we implement something around the deletion timestamp do we need
ot make it optional?
Anjali: good point, should watch this but if we don't make it mandatory,
no matter we need to remember what has been deleted
Nancy: as a next step should we ask for volunteers?
Anjali: yes (Dean Saxe, Eliot Lear, David Brossard volunteered)
Phil: I am Phil Hunt - independent id inc, just nearing the end of
maturity of the draft
Reminder: it is based on security event token, defining events that can
be put togther to be used with the SET transfer protocol, enabling async
sharing about changes occuring in a SCIM env.
Had a use case where a SCIM synchronous request completion could take
hours, so async request completion now in the spec
Provisioning coordination allows muliple parties to call back and get
more information if needed after an event
In draft 5 we removed how events were delivered - went into the spec
originally because folks weren't familiar, that is now out
Now when an event is issued, the final state of the resource is
represented in the E-tag version .
Have updated security considerations, modified attribute syntax and
added an OpenID SSF reference. SSF still needs changes to work with
SCIM, SSF is uni-directional, SCIM is bi-directional.
Next step is for WG last call
Tony: I idn't see anything about timespans, things take a while - what
happens if.. I didn't see a timeout value, if something happens in
between can I time out this event?
Phil : that would be up to the HTTP async request. If you issue issue a
request and if the server supports it it sends error - this is HTTP
stuff not our stuff. When the event comes, it has time of issuance etc,
the requestor knows when the event was issued. That is all specified
Tony: I didn't see it
Phil: that would be a normal SCIM error or a protocol error
Aaron:
Phil: the issue with SSF is when you get to transmitting it, SSF is
about managing streams. I don't see a way editorially that SSF is a
requirement in any normal way
Aaron:
Jen:
Nancy: We did discuss in the SSF wg - we removed the reference to be
sure we had the decoupling
Aaron: I think that was what we were waiting for
Phil: I'd like to have an SSF/SCIM side meeting. It's an SSF issue.
Atul, David, Dean are all interested in the side meeting
Aaron: Phil will organize a side meeting. If you are interested, now
that you are happy with the decoupling we could move the SET profile to
WG last call
Deb: you have to be registered to do a side meeting. If you have an
interim you can invite everyone, but why put them through the
aggravation
(discussion about whether the right people are here to do that meeting)
Phil: It would be useful for those who are here, to set stage for an
official SSF WG SCIM co-meeting. Atul?
Atul: it would help to have a side meeting but I know people who aren't
here.
Aaron: suggest you use side meeting to plan what goes into a future
interim meeting. Don't hear anyone objecting to moving the SET Profile
to WGLC.
Eliot: the doc has been on hold waiting for reviews, got an excellent
security review done by someone who knew nothing to start but did a
great job
People were reading it as if there was an interaction with an actual
device but that is not what the spec was about. Reviewer started to
outline protections about the device, this meant the intro was not good
enough, have cleaned that up and also need to clean up security
consideration
Last thing the reviewer asked for is a cleaner use of how we deal with
certificates where we identify our use of them
I know people (Deb, Nancy) who are well versed in certificates so we
have good people to make sure we are doing the right thing. The reason
we have them is because we need to be able the clients coming in as part
of a provisioning step.
Nancy: do you want the same reviewer to do a recheck?
Deb: ideally you want the same reviewer unless there is some issue.
Eliot: we want to ensure we have reviewed all points with initial
reviewer but then we can do an additional round with others
Deb: the reviewer asked if they would be the same reviewer and we said
yes.
Eliot: only reason not to use same person is they weren't comfortable
with scim. Because provisioining objects contain credentials, we need
extra scrutiny. We need to be sure people are comfortable.
Nancy: we did an early review, Eliot needs to address those
Deb: You got a PKI guy to do a review so that's good
Eliot: it was a great review, glad to get it
Eliot: hoping for a new version by mid-August. Want to start WGLC on
that doc once it is updated.
Nancy: Probably want to review again
Monty volunteered to review again
Kathleen also volunteered
Eliot: document is reasonably stable, so ready for a next step.
Nancy: I also requested an IOT review
Eliot: IOT reviewer gave nits, they are addresssed. Next steps are
reviews, any changes and WGLC