[scim] SCIM Interest Group Meeting Notes for 2021-03-17

[Tim Cappalli <[e-mail]>]

Hi all,

The meeting notes for this week's meeting have been posted to GitHub and are included below:
meetings/2021-03-17.md at main · SCIM-Interest-Group/meetings (github.com)<https://github.com/SCIM-Interest-Group/meetings/blob/main/2021/2021-03-17.md>


# 2021-03-17 Meeting
* Notes taken by Pam Dingle and Tim Cappalli

## attendees
* Pam Dingle (Microsoft Identity)
* Tim Cappalli (Microsoft Identity)
* Danny Mayer (NTP)
* Darin McAdams (AWS)
* Jeremy Palenchar (Orcas Consulting)
* Matt Domsch (SailPoint)
* Phil Hunt (IndependentId)
* Shon Vella (Identity Automation)
* Heather Flanagan ()
* Matt Peterson (Quest)
* Dean Saxe (AWS)

## meeting notes
* Blog Entry from Sailpoint:  https://medium.com/sailpointtechblog/identity-security-standards-you-should-scim-through-sailpoint-390f88f92118
    * Need to amplify!
* Pam to create a page where operating practices are notated
    * For searchability reasons, meeting notes should be sent into the SCIM mailing list (on Monday following the meeting?).
    *
* At some point we need to talk about the timing for Draft Charter

### Phil on History of SCIM
* Restfulness was the new craze when SCIM started
* Everyone had a separate interface - everyone was implementing REST interfaces differently -
* implementations were asymmetric - usually one entity wrote, everyone else conforms to the vagaries of that entity
* REST itself was never standardized
* Lots of folks were veterans of X.509 and LDAP - they had scars
* Rigidity created fragility -- if it was too strict, implementations would fail.  better option is to describe behavior
* Adopted Postel's law (robustness principle)  <- IETF has moved from this philosophy
* Didn't support stateful querying etc because the role/charter was to create a provisioning API not a database.  Returning a result set rather than the whole thing was seen as more DB-ish than provisioning-ish
* The 1000 paper cuts came from pressure to finish  - simultaneous criticism as being over-defined and under-defined
* Could solve these problems in ways of OIDC
    * OIDC test suite encapsulated practices of APIs as well as protocols
    * If SCIM could host a test suite... but it takes $$
* Lots of enhancements discussed but the question is, is there an interop need?
* Paged results
    * Phil thinks it is cool, but paging of multi-value attributes (e.g groups members - ie million member groups) might have more value
* Danny:  notes every place's access is very different (everyone nodded)
* MattD: applications looking to offload authZ
* Phil: can see use for a schema for particular kinds of applications
    * you have to store state somewhere
    * complementary to OAuth Dynamic Registration
* Question: is there a canonical name for the 4 roles (push/pull) or (client/server)
    * Phil: no! nobody was thinking about it back then, at the time all of the data was considered to be behind the perimeter, and also cloud providers had big issues with punching through firewalls, so the dominant paradigm really was one directional
    * We were focused on SCIM clients being request initiators against SCIM service providers (same as HTTP Client and Server).
    * Pushers vs. pullers can begin to be a tricky question (experience from SET).
        * Aside, the SET event model was something we had planned to build SCIM "Triggers" on (see original charter). Could be foundation for Async SCIM.


## actions for next week

* Pam to create iCal list
* Need to get rid of lobby (without inviting Zoom bombers)
* Matt will find that spreadsheet!


## actions for a future meeting
* Paul/Matt:  PAM draft
* "Death by Paper cuts" session
    * Lots of small things getting us down
    * Darin has already sent thoughts on Amazon's papercuts