IETF 119 SCIM Working Group
Monday March 18, 2024 Session IV 17:30 - 18:30 AUT
Chairs: Nancy Cam-Winget, Aaron Pareki
Notetakers: Paul Lanzi, Pieter Kasselman

Chairs Intro - 5min

• Nancy provided a general greeting and introduction to SCIM; reminder
  on Note Well and Code of Conduct
• Nancy thanked the notetakers
• Agenda Bash:
  • Eliot - there is one major issue to discuss - Nancy will give
    the chair update as quick as possible to give time back to
    Eliot.
  • Danny and Anjali - Delta Query may not need the full time
    allotted

Cursor Pagination Chairs Update - 5min

• Nancy in process of doing shepard write-up; looking for feedback
  from Danny and Anjali

  • Thanks for sending intellectual property statements
  • Looking for implementations already done, based on this draft
  • Danny and Anjali to come back to Nancy with any responses to the
    comments provided
  • Haven't heard if Barry felt his comments were addressed?
  • Nancy provided editorial nits, security consideration suggested
    changes --> create another revision accounting for these
    comments
  • Requesting review from Barry/etc - Nancy will reach out to them
    and get their re-review, but she also wants to get her comments
    addressed; Danny notes that he will respond to Nancy's comments
  • Nancy: WGLC completed; but wants to make sure all comments are
    addressed; will let Deb know once the shepard writeup is
    completed

• New AD: Deb Cooley

  • Nancy congratulated Deb

SCIM Use Cases - 10min

Presented by: Pam (Paulo remote)

• Pam will upload slides afterwards.
• Pam will speak to slides (unable to share)

• Paulo and Pam had in-depth debates. Set of plans emerged

  • Set of use cases - 5 excercise all of the core specifications
    RFC 7644
  • Core specifications define SCIM actions, end points and scehma.
  • Try to put those four set of things in greater context. Needed
    for dynamic query for example.
  • Paulo: It would be important to get feedback.

• Pam will upload slides. There are time based mapping and would
  appreciate feedback on that.

• Pam to notify chairs so they can ask for reviewers prior to adopting
  the document.
• Nancy: we can discuss this in the interrims as well
• Pam: Dynamic query is not perfect.

SCIM Events - 10min

Presented by: Phil and Mike (remote)

• No slides presented; Draft 4 is here:
  https://www.ietf.org/archive/id/draft-ietf-scim-events-04.html
• Phil updated latest draft: removing section on event feeds, risk
  signals, a few events already covered by CAEP (or other outside
  events) -- overall the latest draft is mostly removals from the
  previous version
• Draft didn't make deadline for IETF119, but draft 4 is now online
  now
• Mike will upload his one slide
• Paul noted that in conversation with potential implementors, there
  is broad excitement about this draft
• Shared Signals Interop @ Gartner London presentation - SCIM Events
  being available was attractive to the participants there
• Dean: Are additional reviews needed (of Draft 4) to move towards
  WGLC? Nancy: Speaking as author, request Aaron (Co-Chair) to start
  WGLC on Draft 4. Dean: Sounds good
• Atul: Before we go to WGLC, is there anything we need to do w/
  Shared Signals Framework with respect to the SCIM Events draft?

• Mike: May want to hold off on WGLC to let people have more
  discussions about Shared Signals and SCIM Events draft. Don't
  believe they are in conflict, but want to give people time to see if
  there are things that need to be updated.

  • Aaron: noted that Shared Signals isn't mentioned in the draft.
    Want to add a reference? Phil: No, just want the draft to focus
    on defining events. That's why Draft 4 removed a lot of content
    (because it was picked up by Sec Events). Last piece was Async
    events (which called for refecence to SCIM core protocol). Have
    a concern that SCIM Servers are likely both generators and
    receivers at the same time; so only registering to send (or just
    receive) is a worry -- but that doesn't affect Draft 4.
  • Atul: The push/pull delivery referred to in Draft 4 is the same
    as how Shared Signals works (with some additional features)
    which is useful for async delivery. So it might be useful to
    evaluate whether Shared Signal's is a good transport mechanism.
  • Phil: Want to avoid any protocol definitions in the draft and
    keep with clean events defitions only.

• Pam: Picture previously described aggregators/routers - this has
  been removed in Draft 4. Does that mean that we no longer expect
  implementors to do this, or figure it out on their own? Phil:
  Transfer specs describe how things will work for interop; the
  previous architecture diagram was one possible design pattern but
  was causing confusion because people interpreted it to mean that the
  spec called for exactly that design pattern (and it does not). For
  instance, a lot of SCIM servers will be implemented as clusters, but
  some will not -- and we're not descriptive about the right way to do
  it

  • Pam: Understood; but would this negatively impact interop?
  • Phil: No, won't detract from interop as long as they stick to
    the event definitions.
  • Mike: Transport is described in the Shared Signals spec.
  • Atul: SSF is a ready framework to use, but there may be good
    reasons not to use it -- but worth looking at/thinking about.
  • Pam: Appreciate the perspectives; not intending to call this out
    as a problem, just wanted to get perspectives here

• Aaron: What else is needed before WGLC? Mike: want to make sure
  we're clear on the discussion points we just had (potential conflict
  with SSF); if not, then we're fine with WGLC. Some people who were
  catching up on Draft 4 may have further
  changes/suggestions/questions but unsure how major those might be.
  Aaron: Would these potentially be changes that could be handled
  during WGLC? Mike: Not clear what kind of changes are permitted to
  happen WGLC, nor clear on what those third parties' concerns are.
  Aaron: Are there particular people you could reach out to to nail
  this down? Mike: Yes, have a list of people he can reach out to and
  solicit feedback before WGLC. Aaron: Understood; sounds like we
  should wait for that before we do WGLC but will do WGLC after that.
  Note it on the mailing list once those conversations have happened.
  Mike: Agreed, will move quickly to WGLC via the email list once the
  confirmation from the (unnamed) third parties' issues are addressed.

Delta Queries - 20min

Presented by: Anjali and Danny

• Anjali provided context for delta query work

• Two aspects:

  • Full scans:

    • Should full data set be returned

  • Delta query response

• Full scans

  • Obrain first delta token
  • Client completes full scanusing List Users/List Group APIs
  • Use delta token to perform delta scan
  • Benefit
    • Simplifies delta query
    • Use existing APIs
    • Delta query iss an optimization add-on

• Delta Query Responses

  • return changed attributes only in addition rturning full
    resource state

  • Goals:

    • wideladoptable
    • Effiicnet at scale
    • Bandwidth efficient
    • Efficient for client

  • Challenges

    • Define a common scehma for both approach 1 and approach 2:
      all attributes for new objects, only modified attributes for
      modified objects, only metadata for deleted objects,
      especially for SCIM servers that may not be be tracking
      attribute-level changes on modified objects
      • Hard to handle multi-valued attributes

• Anjali: Request contributions.

• Pam: On the full scan side, why is it more efficient?

  • Anjali: No goal is to simplify logic, not optimising for
    efficeincy. SCIM clients canuse existing APIs.

• Pam - what s the actual mechanism, is there a seperate/new end
  point?

  • Anjali - not finalised yet, adressed in next version of spec

• Nancy: we will need this draft to be reveied at some point as well.

SCIM Device Model - 15min

Presented by: Eliot (remote), on behalf of Eliot, Muhammed and Hassan

• Presented slides previously uploaded
• Update recently posted. Now on -03 draft; there will be a -04 draft
• Eliot provided a recap (from the slides) of the SCIM device model.
  Rather than enterprises going out, the partners go in (partner could
  be, for instance, an app). The model is modular, accounting for
  devices that speak protocols like BLE, Zigbee, Wifi, etc.

• Eliot recapped changes since IETF118; working with Jeff Cooper, FDO
  model and Ethernet-MAB have been added (and added to open source
  implementation). Ethernet-MAB is the bare minimum presently but
  provides a bootstrap for higher levels of trust.

  • Active discussion on the mailing list about the IANA
    consideration section; some editorial/nits/language smoothing
    done and also in progress. Eliot requests some help in spotting
    language considerations.

• Eliot observed that, during FDO implementation, they deteremined
  that there are two aspects of work: 1) Configuring/provisioning the
  network and 2) Transfering the ownership. For instance, FDO, might
  include several operations that take actions beyond just getting it
  on the network (whereas other models might just be about getting the
  device on the network)

• Big issues remaining (slide is non-comprehensive list) -- but clock
  is running on getting a proposal submitted

  • Versioning - separate numeric versioning may be too complex
  • Extensibility - if new extensions just get a new name, it can
    make versioning simpler
  • Other models: RFC8995 vouchers... but want to make sure we
    understand the implications for the SCIM servers. In the voucher
    case, we'd be passing a PIN'd voucher to the server - which may
    not comply with the RFC8995 spec?
  • Reflecting on Paul's work with Pam on Use Cases - could use a
    terminology shakedown
  • Would like to kick off an early review in Security, as that's
    always a good idea when we're touching something in SCIM
  • Request that non-IP device provisioning proposals come in sooner
    than later

• Want to get all issues resolved (including those in the Issue
  Tracker) in the next month so that it's all stable enough to get to
  last draft in May

• Pam: Yes, would like to collaborate on terminology shakedown
• Pam: Technical note: RFC7644 descirbes /users (plural) and /groups
  (plural) but /device (singular) is defined in the draft. Should/can
  it be plural to match the others? Eliot: Yes, we can make that
  update. No objections.
• Monty: Noted that he and Eliot are in agreement about how to
  proceed. Eliot: One more phone call might reach conclusion. Monty:
  Noted that he just came from LAMPS and had a parallel problem - lots
  of different devices and didn't want to hardcode every possible way
  into the RFC. In their case, they established an IANA appendix that
  covers the same kind of material that Eliot has in Section 7
  presently. Eliot: We should talk through what is needed for an IANA
  entry (i.e. a specification that covers a handful of things); will
  talk through this with Monty. Biggest issue seeking feedback on is
  versioning of the extensions themselves. Want to keep URN from
  containing too many version strings; wants to bring a proposal that
  simplifies things (by making a new extension name). Monty: Feels
  this shouldn't even be in the spec; it's "their problem"; seems he
  and Eliot are in agreement on this point.
• Eliot: Would like to invite anyone who wants to to contribute to the
  open source. Refactor of code is in progress but will stablize in
  next few weeks. Abstracting out what used to be very BLE focused.
  Welcome more contributors! Coders wanted.
• Pam: Do you have an liason in the FIDO alliance for FDO? Eliot: not
  officially; Jeff and Eliot were meeting once or twice a week on it.
  Pam: Believe there is a new coordinator in FIDO alliance; will
  bridge that intro for Eliot. Eliot: noted that an FDO voucher is
  being passed through the SCIM provisioning system -> the owner
  process in FDO, so you don't have to deal with email, but rather
  just hand this voucher to the owner process. This is an efficiency
  step to pass the voucher into the enterprise. If there are other
  objects needed, now is a good time to identify those.
• Nancy: Are you requesting for an early security review? Eliot: Yes.
  Nancy: Sounds like you are still updating the draft; should we wait
  until that's done before we do the security review? Eliot: yes, wait
  about 2 weeks for us to respond to editorials but due to this
  involving passing credentials, we want to hear from security. Nancy:
  will wait till a new draft is posted (or Eliot reminds her).
• Eliot: Matter has become quite popular, but it's not ready for
  enterprise. Will probably be a future extension as Matter and
  Enterprise come together. Clarifying: won't get to Matter in this
  draft because we don't (yet) know what to provision -- due to
  Matter's enterprise notions not being mature yet (though those are
  in the works). Don't want to take guesses at the extension at this
  point. Nancy: Not clear to her that Matter's charter is inclusive of
  Enterprise -- more consumer focus. Eliot: Expect that they'll
  stretch for enterprise later.

(meeting concluded nearly precisely on time and after finishing all
agenda items)