IETF SCIM 117 WG Notes
26 July 2023
Location: San Francisco Hilton, Continental 8-9

Scribes: Pam D, Paul L

Welcome - Nancy & Aaron

• Reviewed notewell
• Agenda change: will start with SCIM Devices draft instead of Use
  Case document review

SCIM Devices - Eliot Lear (via Meetecho)

• Draft:
  https://datatracker.ietf.org/doc/draft-shahzad-scim-device-model/
• Slides:
  https://datatracker.ietf.org/meeting/117/materials/slides-117-scim-scim-for-devices

• Presentation:

  • goal is to abstract the lifecycle of different kinds of devices
    (eg zigbee)
  • Core schema is common
  • extensions for BLE, WIFI, Zigbee, endpoint applications for
    control/telemetry
  • WG adoption closed, possible hackathon in Prague
  • OSS code soon
  • Expect at least one more comment to come through in coming days;
    chairs can choose await that comment?

• Nancy:

  • we seemed to have good support for the call for adoption
  • at some point the process will be closed (this week)

• Danny Z: question on usage of devices namespace, everything is
  aligned to IoT devices. Other folks may want to use that namespace
  in the future

• Eliot: welcomes ways to stretch or constrain the device. Open to
  suggestions
• Darrel: /me is a problem, you end upconficting with more
  cross-organizational endpoints, more negatives than positives.
• Aaron:

• Use Cases document (RFC 7642) update: Pamela Dingle & Paulo Correia

• Draft:
  https://github.com/pamelatech/scim-use-case-revamp/blob/main/draft-correia-scimusecases-00.txt

• Slides:
  https://datatracker.ietf.org/meeting/117/materials/slides-117-scim-scim-use-cases-slides

• Presentation:

  • Draft is ready and will be submitted once datatracker reopens
    after IETF117

  • Base concept review (Pam)

    • Orchestrator roles: new concept in this draft. Includes
      Resource Creator (RC), Resource Updater (RU), Resource
      Manager (RM), Resource Subscriber (RS)

      • These roles help define the direction of the data flow,
        as SCIM Servers and SCIM Clients can both push and pull
        data. These roles are distinct from the HTTP verbs in
        use.
      • For example, RS = Consume data only

    • Resources

      • Resource Object (RO) - set of attributes for specific
        resource
      • Resource Attribute (RA) - a single attribute

    • Triggers - causes a SCIM action to be performed

      • Could be periodic, event-based, adminstrator-action
        driven, user action, single sign on (i.e. for
        Just-in-Time account provisioning)
      • Seeking feedback on which of these terms are important
        for implementors to understand

    • SCIM Actions: Push or Pull to: Create, Update or Delete a
      SCIM Identity Resource

  • SCIM Use Cases review (Paulo)

    • Carried forward existing Use Cases, such as /me, that have
      doubtful implementation history. Could consider to drop
      these.
    • IdM doing CRUD ops on a SaaS application
    • IdM doing CRUD ops on a SaaS application and Objects coming
      from External SCIM source
    • IdM doing CRUD ops on a SaaS application and Objects coming
      from External SCIM source AND non-SCIM source including the
      IDM itself
    • IdM doing CRUD ops on a SaaS application and Objects coming
      from External SCIM source AND non-SCIM source including the
      IDM itself, where some object attributes come from SaaS
      application
    • • IdM doing CRUD ops on a SaaS application and Objects
        coming from External SCIM source AND non-SCIM source
        including the IDM itself, where some object attributes
        come from SaaS application and are updated in the SCIM
        object creator

    • Multiple IdM doing CRUD ops on SaaS application, and Objects
      coming from external SCIM and non-SCIM sources including the
      IdM itself, where some object attributes come from SaaS
      application, and are updated in the SCIM object creator

    • Are there other roles or use cases missing? We are seeking
      input...

  • Next steps (Nancy)

    • Submit in IETF Datatracker

• Discussion regarding /me endpoint:

  • Leif: /me was designed for a different indempotent version of
    SCIM. Would recommend to depreciate it.
  • Darrell: We use /me; need this for cross-domain efforts. Would
    not implement it.
  • Phil: Oracle, possibly SalesForce, requested /me in regards to
    OATH to avoid having to search for user first - just grab it
    from the currently authenticated user
  • Hans: 2 things - the implementation but also the use case. Just
    because we get rid of /me doesn't mean we should get rid of the
    use case.

Cursor Based Pagination (Anjali Sehgal and Danny Zollner)

• Draft:
  https://datatracker.ietf.org/doc/draft-ietf-scim-cursor-pagination/
• Slides:
  https://datatracker.ietf.org/meeting/117/materials/slides-117-scim-cursor-based-pagination

• Presentation:

  • Lots of discussion over multiple sessions, minor edits since
    Yokohama
  • Feel like it's ready for last call

• Discussion:

  • Anyone not happy with a last call?

    • (no complaints)

  • Discussion about doing WGLC and an early SECDIR review for this

Group Membership Pagination (Danny Zollner)

• Slides:
  https://datatracker.ietf.org/meeting/117/materials/slides-117-scim-group-memberships

• Presentation:

  • Today pagination applies to responses that contain multiple
    resources, no way to paginate objects with large multi-valued
    resources
  • Anything involving group membership retrieval (for example) is
    impossible at large scale due to data volume returned
  • Possible solutions
    • Options include a draft by Phil Hunt,
      draft-hunt-scim-mv-filtering-00
    • Schema extension to introduce group memberships as a
      resource
    • Protocol/schema extension to introduce mechanism to
      represent any multi-valued attribute as a resource
      • Represent multi-value attribute as a subresource
      • Allows reuse of existing 'resource' concept within the
        multi-value attribute domain

• Discussion:

  • Leif: if this is just about group memberships, can we flip the
    membership around and have it be an attribute of users instead,
    makes the logic easier. In his experience there are as many
    groups as users, more efficient to represent groups as
    attributes not objects. Understand there are reasons for both,
    just wondering if there is an opportunity with this spec to do
    something there.
  • Danny: that has been discussed on the list, it is achievable as
    an option
  • Phil: have you considered using the group attribute of the users
    object. (duplicate of Leif's question)
  • Leif: this could add complexity that will have a cost. Worth
    asking whether groups really are the only use case. (Danny notes
    that we don't know what we don't know)

• Next Steps:

  • Danny: will solicit feedback on the mail list

Delta Queries aka Change Detection - (Anjali Sehgal and Danny Zollner)

• Slides:
  https://datatracker.ietf.org/meeting/117/materials/slides-117-scim-scim-change-detection

• Presentation:

  • Problem statement and solution requirements:

    • Change detection - allows a SCIM client to get current state
      of all resources from a certain point in order to perform
      recurring incremental retrieval of data
    • Sometimes, systems get out of sync and the only option is a
      full fetch of all resources which can become resource
      intensive
    • use cases include reconciliation and incremental update
    • Goal is not a snapshot, the current state of the resource
      is always returned
    • This may require keeping metadata about changes so that it
      can be returned as part of this kind of query
    • Need to perform at large scale
    • Need to refer to no-longer current objects (ie deleted
      objects)
    • Ability to know that a record was deleted

  • Approach 1: Timestamp filter

    • Today you can make this request but deleted users are not
      included

      • may need a way to request that deleted users are
        included

    • Pros: already implemented, but including deleted users would
      require new functionality

    • Cons: possible issues with time drift, could be mitigated by
      intentional overlaps in time windows

  • Approach 2: Change detection via watermark

    • opaque artifact generated by SCIM Server
    • starting with a full retrieval, then at later date ask for
      additional data since the watermark
    • has potential to be more accurate due to lack of sensitivity
      to time drift and time differences between the client and
      the server
    • ultimately provides more flexiblity to implementators that
      lack a timestamp-based internal change journalling system.
    • Can optionally encode / contain a timestampe as a the delta
      token if that's easier for the implementor
    • It will be more expensive for implementors if they do not
      already have a change journalling method
    • clients may still need to do a full sync if there is
      corruption or other use cases (including possible deletion
      of the change token)

  • Open items for discussion/input

    • Danny: Will be sent to the mailing list and appreciate in
      advance the input!

• Discussion:

  • Leif: is the delta token global or is it mediated by the
    relationship between client and server (would two clients get
    the same token?)
  • goes to implementation cost. Must think about how hard it is to
    implement. Client-specific states is a big lift.
  • Aaron: that may not be relevant to the protocol, is more of an
    implementation
  • Danny: hasn't been considered enough to have an answer now
  • Mike K: have implemented this at Sailpoint, we find a full
    aggregation is useful for a "standing check". Timestamps seem
    easiest/more common, then hand it back as a timestamp on the
    target system. Other times, there is more of a token approach.
    Keep time on the (client?) side, to decide when the token needs
    to be redeemed
  • How common is soft-delete, staged-delete, how much of a burden
    is there for those systems to implement 'isDeleted'
  • Pam: client-specific delta tokens > does possession of the token
    inform some level of access? The spec should be opinionated
    about this and not left as an implementation detail. Danny:
    Likely not convey any access; just as a delta query start point
  • Darrell: How do you page through the results of a query returned
    from a delta query? Danny: Likely use cursor or index based
    pagination to go through the results of a delta-token query;
    Anjali: every page request would need to include the token in
    the URL -- so the query would contain both the delta token and
    the page #
  • Mike K: The information you bring back drives whether a change
    occurred or not... for instance, including "last login" as one
    of the attributes for which change detection is enabled will
    result in a larger change set than not including "last login".
    Recommend to think through best practices as the draft is
    elucidated. Danny: Don't necessarily intend to write a delta
    query mechanism that is univerally useful for all use cases -
    still expect that some use cases will require fully sync. Gave
    example of HR use case.
  • Pam: Re: Darrel's question, is this draft tightly coupled to the
    cursor-based paginati draft? Danny: Have a preference to have a
    single approach (rather than two) to avoid interop challenges.
    • Aaron: Confirming that there is no actual requirement
      dependency and that it could be implemented using
      non-cursor-based pagination?
    • Danny: Appreciate clarification - would like it to be
      dependent, given the scope (accuracy, reliablility) of the
      goals for delta queries; specific concern about
      live/changing result sets.
    • Mike K: Prefer to leave the drafts independent as the
      problem sets are independent
    • Danny: Understood -- agree that cursor-based pagination is
      not strictly required; feedback understood

SCIM Events - (Phil Hunt)

• Slides:
  https://datatracker.ietf.org/meeting/117/materials/slides-117-scim-scim-events
• Draft: https://datatracker.ietf.org/doc/draft-ietf-scim-events/

• Presentation:

  • Couple of changes to the spec, had to restructure event URIs,
    re: IANA namespace -- there is no SET event registry, needed to
    move the events under the SCIM registry instead.
  • added a new attribute to discover whether async events were
    supported

  • Async SCIM request (example)

    • SET 'transaction' value == transaction ID. in the Location
      field you can (optionally) find a URI where you find out if
      the referenced transaction has completed
    • 'events' attribute includes the SCIM response that would
      have originally been given

  • New ServiceProviderConfig attributes

    • asyncRequest > NONE (not supportd), LONG (only async if txn
      runs longer than set threshold), REQUEST (will always
      respond asyncronously)
    • eventUris > An array of event types supported by the server.
      For instance, might only support CRUD ops. Informational
      only. Just because a server can generate an eventUri doesn't
      mean that it necessarily will.

  • Demo and discussion

    • i2scim.io - open source Java-based SCIM Server

      • 8936/8936 (SET push/pull) - both useful for different
        reasons

    • Stream recovery - heard that this was important - to be able
      to reset to date/time or JTI

      • being worked on by OpenID SSF group

    • plan to publish soon

    • Demo scenario: SCIM Server 1 and 2 are exchanging
      information by goSignals. Includes echo back to original
      server which then rejects the transaction as a duplicate
      transaction.
    • Demo provided

• Discussion:

  • Async SCIM request
    • Darrel: If you prefer async, is it expected you return this
      preference only. 7240 indicates that a response header
      should include this. Phil: Discussion of HTTp/200 vs
      HTTP/204 response; will look at this and refine it.
    • Darrel: note that location header values are generally not
      quoted. Further, we're not supposed to use location header
      for this but everyone does. Phil: UnderstoodDa
    • Danny: curious whether there is a need for a 4th attribute
      of "always"
    • Phil: this is what the LONG value is
    • Danny: but what if the server wants to only use async
      requests
    • Phil: that would be a change
    • Darrel: Spent a lot of time looking at LONG. Note that there
      is also a WAIT. Looked at 202 responses and only 0.6% of
      clients bother to poll after the fact; it's hard for
      developers to write polling loops. Expect a lot of clients
      will just stop after 2xx response.
    • Phil: Heard from developers that holding open HTTP
      connections indefinitely wasn't good, so are giving two
      mechanisms. Would prefer to just give one mechanism (event
      streams) but seems we need two. Would invite more discussion
      about this.
    • Pam: It's important for the client to check back in on the
      async-status'd transaction, yes? On, for example, a
      transaction that fails > clients that don't check will
      assume it succeeded and clients that do check will see that
      it failed. Phil: With respect to goSignals, async stream
      system takes care of replication in the background. For
      example if the company is using LDAP but receiving SCIM
      events, could get the event from SCIM and then take
      business-specific logic (i.e. go make LDAP changes). SCIM
      servers are up to date and don't have to keep track of
      cursors, etc-- they just publish the event (just like they'd
      have sent a log).

• Next steps

  • (none discussed)

All Other Business (AOB)

• Unofficial side meeting to take place tomorrow 11:30am @ Continental
  2-3