Agenda

Agenda Bash & Logistics - Nancy Cam-Winget

Charter and Milestone (markers) review - Nancy Cam-Winget

SCIM Introduction & Existing Spec Review (RFC 7643/76440) - Janelle Allen and Danny Zollner

Use Cases & Concepts (Updating RFC 7642) - Pamela Dingle

Multi-value Filtering Extension (draft-hunt-scim-mv-filtering-00.txt) - Phil Hunt

SCIM Extensions (draft-zollner-scim-domain-extension/ and draft-zollner-scim-roles-entitlements-extension/) - Danny Zollner

Tooling and Next Steps - Chair: Nancy Cam-Winget

Session Notes

Nancy - I tried to pre-load the agenda, in the interest of time a 2nd scribe would be great. Welcome to our first official continuation of the SCIM WG, the session is being recorded

There may be a few of you that are new, there are notes to take with respect to privacy (the Note Well) we will be following IETF privacy processes, please consider the Note well. Meeting tips: stay muted, we track attendance through blue sheet but now it is automatically taken. There are chat rooms, if you need assistance there are links. Code of conduct: as we participate we should extend respect/courtesy. We are a diverse group.

Notes are live, could use help as Pam will present in 3rd slot

Barry is co-chair and will help run the session.

Charter link: https://datatracker.ietf.org/wg/scim/about
Other SCIM Working Group links: https://linktr.ee/scimwg

Milestones are a stake in the ground on what are markers for rough targets of where we want to be. Not the final thing, the WG gets to decide how to move forward

Intro presentation - Janelle & Danny

(Janelle)
Janelle Allen - introduces herself, Danny Zollner - both are product managers, Danny at MSFT, Janelle at Cisco

what is SCIM? released 2015 and been around. Designed to share identity data across context. Normalizing & abstracting data away from where it was residing
consists of comms protocol & core schema and comes with an extensibility model
designed to be fast cheap and easy to use
takes away need to know if data is in SQL or LDAP
enables scale
Example - Jane Smith
Asset in a database fronted by a Service provider, data is transformed into standardized JSON format, client can interpret the dat prior to storing on the other side
RFC 7643/44
- uses RESTful design, verbs are matched to common CRUD concepts
- Standardizeds methods for clients to communicate with Service Providers

(Danny)

shows chart of standard endpoints
/users, /groups come with a core set of attributes, and an enterprise schema with a few extra attributes is included
/me method to allow an authenticated user to read data about themselves, eg an internal application might use /Me to update a user password
/Schemas - retrieve attribute schemas
/ResourceTypes - discover what resources are available including custom
/ServiceProviderConfig - discover extensions and advanced support
.search - alternative to a GET, submit query using POST
/Bulk - submit query with POST, body contains series of operations together

(Phil) The reason for the POST in .search is to protect PII
(Danny)

examples of SCIM: searching /Users with a filter using a username & GET exposes that username
two methods to update object- PUT describes all attributes, any attribute without a value is set to NULL
PATCH non-destructively augments attributes
DELETE lets you delete the resource
Core Schema and Attribute Data Types - a minimum common set. Extensible, resource types can be created custom. Examples might be /ConferenceRooms, /Contacts - custom schemas may be registered by IANA but generally nobody has registered their custom work.
- Reviewed several examples, including complex attributes
- Review of data types
We are here because there are wrinkles in SCIM and we want to address them
Issues like lack of clarity, arguments over how the spec is implemented, limited guidance on handling entitlements, are some examples
We seek to improve the usability
Some companies have noticed issues with Bulk operations, some want different pagination qualities, others want to extend schema
There is a link to a document containing papercuts, we encourage everyone to read and add their feedback
Goals of SCIM moving forward include
- removing ambiguity
- Areas of focus include soft delete, HR-related use cases, advanced automation scenarios
Full list is in charter. Questions?

SCIM Use Cases and Concepts - Pam Dingle, Microsoft

Review of RFC 7642 - Definitions, Overview, Concepts & Requirements (information status)
Consists of three publications 7643 and 7644 along wtih RFC 7642
Look at the fit for purpose of exisitng rfc7642 (informational status)
Defines the names of actors which use the SCIM standard
- Actors Cloud Service Provider
- Enterprise Cloud Subscriber
- Cloud Service User
The interesting thing is that there is no exact correlation between a Subscriber and a Provider in the actual protocol leading to confusing and ambiguity. New use cases, including Just In Time use cases, have emerged where the direction of data flow is not the sole definer of that actor’s role in the SCIM exchange (for instance, a service provider that needs to ‘push’ a change to clients)
Points out there are sometimes collisions with the terms
Introduces concepts introducted Triggers, Modes and Use Cases
Pam indicates she is trying to call to action those to join WG to improve
Is a subscriber a client? not clear with the doc rfc7642
Is not sure people are aware of rfc7642 in practice today and again call to find colleagues assist to improve this doc
Privileged Access (including cross-domain elevation of privileges) has emerged as a critical use case – unsupported by current RFC7642 descriptors
Incorporating modern technologies such as webhooks did not exist when these RFCs were created, other identity concepts such as OAuth didn’t exist
Calls out that people implement for the happy path or successful access but lack testing for the negative such as users not being able to access a system
Relationship between Cloud Providers and Clients (including: between Cloud Providers) is changing and adapting
Attackers are following a well-known attack path: create a privileged user, execute some sensitive processes, then delete the user – thus using/abusing provisioning as part of the attack path

How Clients Implement bi-directionality

Pam reviewed several examples, including SCIM Client <> Service Provider wherein push and pull are happening together (albeit, verbs differing by attribute). Takeaway: Any participant in the exchange change can either be acting as a Client or as a Service Provider. RFC7642’s shortcomings include: lack of clarity in describing how this pattern should be implemented.
Points out multiple authoritative sources of data HR might be authority on the user creation yet client may be authority of the email address no guidance for how to keep data in sync in the spec.
Discussion of Provisioning Chains - where Client calls a Service Provider, which then relays to another Client. For example: local tool calls Google to provision a user, and then Google calls a client to push an update as a result of that provisioning activity
Introduces the term a “Provisioning Hubs” where a Service Provider or a client can be a provisioning hub
Directionality of a individual transactions may (and does often) differ from the ‘role’ (Client vs. Server). This Multi-Role Data Distribution is implemented in the world today, but not described in RFC7642 today

What can we do to align documentation to implementations?

Update RFC7642 to describe extensibility, bi-directionality, custom schemas, syncronization, etc. that already exist in real-world implementations today
Add more nuanced use cases that have emerged since RFC7642 was originally drafted, for instance, incremental data attribute exchange
Updated use cases will change (in a positive way) how the actual specification is intrepreted and implemented - including possible updates to RFC7643 and RFC7644 to reflect these use case changes and explications
Request for volunteers to help with updating RFC7642; goal is to update document and submit to WG for consideration. Contact email distribution list (or Pam Dingle directly) if you are interested in helping.

SCIM Multi-Value (MV) Filtering - Phil Hunt

Created draft-hunt-scim-mv-filtering-00.txt after RFC7644 was released and after discussion on the email list in 2019
Need: Enable filter values returned from complex multi-valued (CMV) attributes (by filter, or by index)
Enhances SCIM ‘attributes’ parameter by appending “[]” (value path notation) and specifying the valueFilter. This allows you to specify which sub-attribute or filtered value you want back. Can still request based on count parameters (i.e. only give me 10 rows)
Draft also defines: 1) meta.attribute.cnt to indicate the number of results available; 2) Feature discovery parameter in /ServiceProviderConfig (to tell you if the Server has implemented this)
Phil provided example of requesting only emails where type = work; second example where multi-value paging request with &count=5&startIndex=1 (to specify a range)

Discussion and next steps:

Privacy and Security Considerations - need to be added but will basically fall into the existing considerations of RFC7644
Depending on where the WG goes re: SCIM revision, this RFC could be rolled into an enhanced SCIM core specification (RFC7644) draft or else MV Filtering could remain as an extension
(Nancy) - Phil are you volunteering to be an editor on the core spec?
Phil: laughs
This is why I didn’t want to do the final privacy & consideration pieces, because we don’t know what the final disposition is. I would like to see enough people to show interest prior to taking it further
My colleague Gregg Wilson did say that Oracle intends to implement this shortly
(Nancy) - taking an action item here

SCIM Extension Drafts - Domains, Roles & Entitlements - Danny Zollner

I’ve written two different drafts (my first two internet drafts)
I see two different gaps that can be fixed by adding simple extensions
First - verified domains. Email providers, anything with a hint of security - like to require the ownership of domain names.Eg contoso.com must be verified before user data is saved with that content
If a client is trying to provision a large set of users into a Service Provider (eg a collaboration platform), the userName ends up following user@domain.com format, what is undetectable is what the username reuirement might be (eg danny@domain.com vs dzollner@)
If the client has data coming in that doesn’t align to the service provider, requests will fail. For example if you haven’t proven ownership of the domain, the request will fail. This is easily detectable and avoidable
Goal here is to add a /verifieddomains endpoint so that clients can understand the context and avoid sending requests that will fail
The extension adds /VerifiedDomains resource, only GET supported
Some requirements exist over only allowing domains from major providers, but there are considerations that caused me to leave that aside.
Schema of the VerifiedDomains resource - the domain name, a setting for whether subdomains are allowed, and the date when the domain was verified. Subdomains such as europe, apac etc may or may not be desirable as included
ServiceProviderConfig - contains boolean to indicate support, and a complex type describing the userName format
- also contains emailVerifieDomainRequired - boolean that states whether all emails must be from verified domains
Questions for the group - is RFC 5321 the correct RFC for userName format?
Any feedback on how to make this more clear is appreciated
(Pam) - what if only three subdomains are needed, does the boolean mean an implementer can’t be specific?
(Danny) - no, each subdomain can be specifically entered into the list

Roles + Entitlements

Goal is to help clients discover acceptable values for user resource roles/entitlements
Should help whoever is configuring to get a full list and then represent them in a UI so that they could be assigned to other resources as appropriate
Schema mimics existing sub-attributes, resources would have vlaue, display and type plus the new attribute “enabled”
discussion of example for ServiceProviderConfig
Question: how widely adopted is the type sub-attribute for roles and entitlements?
If we are giving a once-over on 7643/44, if there are major changes, is it worthwhile to look at whether existing role work is sufficient. Should this extension just be part of the new spec?
this extension could be adopted now but then rolled into a greater SCIM 3.0 effort

Procedural Stuff - Nancy

Tooling: Nancy brought up the idea of using Github
- a mechanism for openly sharing documents, plus a place for comments and interactive issue tracking
- IETF has guidance in RFC 8874 (https://datatracker.ietf.org/doc/html/rfc8874)
- Tutorial at https://ietf-gitwg.github.io
typically only adopted documents are stored, not proposed documents.
Re: Communication channels
- IETF doesn’t have an official slack “account”
- Will officially run the consensus calls via the SCIM mailing list. This is where all questions, topics, etc must go they will always be confirmed
IETF does have an issue tracker but nobody uses it
Have put a poll out to raise hands
Raised hands: 11/11
Nancy - unanimous consensus for adopting Github
Carsten - Github is for the fine-grained work, I-Ds and mail is for getting progress in the process
Roman - it is more than just final steps
Barry - editors still need to periodically post drafts to the IETF process to gain consensus
Nancy - do we want to have virtual interims, and do we want that process to be informally as needed, or on a cadence like bi-weekly or monthly?
POLL: Does the SCIM WG wish to continue with virtural interims
9 positive responses
Question: As chair, I could commit to a montly cadence - objections?
- Pam - monthly cadence is great, happy to have the chairs run things, it means process is observed
Nancy: Will take it to mailing list to discuss volunteers who can take the pen for these drafts
- Danny, Janelle volunteered for schema + protocol
Nancy, Barry thanks all, thanks to Pam/Paul for scribing
Roman - congratulations on this successful launch, thanks to leadership from Nancy and Barry, looks like we are in a good place to move forward!
lots of thanks in the chat, meeting ends