SCIM - IETF 113

Wednesday, March 23, 2022 2:30pm

Chairs: Aaron Parecki [ap], Nancy Cam-Winget [ncw]
Notes Takers: Ned Smith [ns], Pamela Dingle [pd]

Agenda

• Agenda Bash & Logistics
• Use Cases
• IoT Use Cases
• Protocol
• Schema
• SCIM Events
• AOB

[ncw] - Meeting logistics and co-chair into Aaron Parecki
[ncw] - Poll for who is here for the first time and Note Well review. Online meeting tips provided. Attendance recoreded via QR code or via MeetEcho. Code of Conduct review.
[ncw] - Agenda bash - Charter requires update to use cases. Editors are asked to provide dates and progress. Elliot will speak to use cases for IoT. Phil has a draft for profile on shared signals and events (SSE).

Use Cases

Link: https://hackmd.io/71rPgCGDSmyNDy3AUW2MLA?edit

[pd] - Pam Dingle - Microsoft - There is an outline bash for use cases online.

• Background - RFC series of three docs: RFC7642, RFC7643, RFC7644. These don’t document everything an implementor might need. There is a need to update an I-D to capture missing info.
• Soliciting input regarding the goal.

[??] - OpenAPI/swaggar - is this on the table? Is this part of the charter?
[ncw] - No. It isn’t explicit in the charter.
[el] - Elliot Lear - Slightly dissenting point of view. Not sure it stands up to the use cases being considered.
[pd] - Presting an outline for the use cases and concepts implementers need to use scim.

• Next section is the Concepts section related to provisioning. What does it mean to have a “start of authority”.
• Master-slave or bi-directional sharing?
• Just in time prosioning
• Mutability and uniqueness - not just a definition but an explanation of why they are necessary. The concepts becomed linked in the definitions.
• API security - Explain how a scim endpoint can be secured. If it is too obvious please leave a comment inline.
• Hard and soft deletion
• Privilege elevation
  [pd] - Does anyone want to comment on the altitude?
  [el] - These are good, but not an exhaustive list. The question to ask is anyone objecting to what’s in the list. We might add more over time. For example, talking about data directionality, but what about connection directionality? Is a RESTful protocol the RESTful protocol.
  [ncw] - ran a poll on whether anyone wants to object to anything on the current list.
  [roman] - Guidance that this is a great starting point.
  [pd] - Last interrim meeting we discussed what a use case means, in terms of the rationality - negotiating schema, object synchronization, data set maintenance. These can be broken into subsections. But not certain these are sufficient. Management at scale is an area to spend more time - e.g., how to do bulk operations, pagination etc.
  SCIM has two layer (a) how to do it (b) how to do it at scale.
  [ja] - Janelle Allen - Excellent points raised, but there is data that is transferred such as URL to a photo where how we deal with sensitive data or how to access itr how to access it
  []
  [ns] - having technical issues with HedgeDoc
  [pd] - My hope for the scenarios was hopefully to tie end-to-end scenarios. If you don’t see something that resonates then it is the wrong list (of use cases). Provided an example involving cloud platforms and schema negotiation / checking might work. Need to talk through the less commonly used features. E.g., account group data reconcilliation. The implication of reconcilliation might be the system lost connection etc… How do you know you’ve missed something? This is the difference between brute force download vs. incremental update.
  [pd] - Another UC involves progressive profiling and user managed service.
  [pd] - The last is bulk address change. You would want to search with a filter to match buildings (old vs. new) and incrementally change accounts where the buildings changed.
  [pd] - There’s no group management today. The idea of how you replace a user in a group of 1M users that scales.
  [pd] - Extending schemas and how to accomplish. This is story telling at the end of the day.
  [pd] - Suggest running a poll
  [a] - Antione - How do you manage change of ownership on the devices? One thing is management of the company sales over multiple years. There’s a need to manange change in authority.
  [el] - I wonder if we can defer the poll until after the IoT presentation. We don’t want to format everything upfront.
  [pd] - Happy to take that advice.

SCIM Device Use Cases

[el] - Showing slide of two pics (a) portrait (b) light bulb - how are the different?

• Showing slide that motivates why SCIM is needed. Provisioning is a key function. Maybe a need to create, delete, update or group devices. Just getting going so there may be others.
• Showing slide showing key goals. Objective is to do as much automation as possible including transfer of credentials relating to a device. Devices need proof they’re connecting to the right place as much as network needs to know they’re connecting to the right place.
• Unlikely L2 technologies or above will coalesce to a single provisioning protocol.
  • contention is that a “fully normalized” method is needed
• Showing slide of a connection graph from device to various endpoints. There isn’t likely to be a consolidation soon - no technology religion. 8366 voucher but there are alternatives for onboarding.
  [lj] - Leif Johansson - Various types of keying material might require an update to scim. Today everything is based on bearer tokens. If you used a token translator approach to talk to scim server. How is this a problem for scim?
  [el] - Note that the IOT device does not ever change.
  [lj] - Why does a wide range of keying material affect scim?
  [el] - what we’re talking about here is about creating a device scheme inside SCIM - it is a schema issue.
  [lj] - Its a schema issue
  [tc] - Tim Cappalli - I think this should be positioned as devices not IOT
  [el] - I only mean devices (not just IoT). The use case envisioned was cloud based provisioning of a large set of devices. The enterprise provisioning case requires directionality - “add device to inventory” vs. “add device to network”.
  [el] - Slide showing Summary of varience from normal SCIM. The connection direction needs to be discussed in more detail. Device identities need clear scope, esp. if there are multiple suppliers. One enterprise provisioning operation shouldn’t affect another enterprise. Extensibility remains important, SBOM - hot topic in US / EU. Device type information. Onboarding needs to include info about the device not just its ID.
  [el] What is the relationship between users and devices. Should an owner be assigned? It isn’t clear that the supplier needs to set this. But that doesn’t mean there is no UC for assigning owners.
  [el] - We need a schema language to describe this. Need real $refs for polymorphic purposes. Initially used JSON-schema. Swaggar was frustrating - raised for comment.
  [en] - Eric Nordmark - Suppliers provide credential information. But need information on who is adding the device to the network. It isn’t clear the communcation issue changes. There can be grouping activities as well.
  [el] - I think you can see it both ways - both models are reasonable to pursue
  [tc] - There is a bootstrap IDP and ??? IDP. There are differences that drop in and needs to be added to the flow.
  [el] - This doesn’t talk about what happens once the Enterprise receives the info. Presumption that there is a difference but Conversion from IDEVID to LDEVID etc… SCIM doesn’t need to go into this detail, just focus on the transfer.
  [el] - That’s it.
  [tc] - Very supportive.
  [ncw] - The last question was I-D? What is the goal of the uses cases. They should define the goal in terms of the way forward. A potential ave is to incorporate these ideas into the use cases. Or there could be a proposal to identify the update case???
  [el] - What does Pam think?
  [pd] - I think the question is “is it a draft” - do we need to answer this or something else.
  [ncm] - we need to create a separate UC draft to that the content could be incorporated.
  [pd] - I support that approach.
  [ncw] - Can poll - Is the HackMD content presented by Pam and Elliot’s IoT UC sufficient?
  [pd] - We have to decide what UC the concepts applies to. Writing to the existing RFCs would be different from the new work.
  [ncw] - We discussed in 112 and VI, but didn’t conclude if the updates were to scim 2.0 or if the updates would create scim 3.0.
  [ph] - Phil Hunt - technical difficulties
  [ncw] - [ph] - Elliot’s draft is new and not a comment on an existing UC.
  [ph?] - everything that can be split apart should be.
  ncncw] - Is it OK to incorporate into UC draft then decide what gets split?
  [ph?] - Yes.
  [el] - Fine with breaking up work wherever possible, but there is schema work too.
  [ncw] - That’s why it needs to be captured as a UC first.
  [dz] - Danny Zollner - ???
  [ph] - @Elliot - could be a new draft or new schema, but along with devices we need authenticator schema, and a reverse flow.
  [ncw] - You’re speaking to the technical solution. But should we refer to IoT UC as an update to the current UC draft?
  [ncw] - well over time - running poll now.
  POLL - should we incorporate the IOT use case in the base use case draft?
  Raise Hand 24 , Not raised 4 , total - 28
  -technical difficulties-
  [ncw] - next topic - technical difficulties -

Scim Schemas and Protocols Work

[dz] - Tribute editors for schemas and protocols.

• Current Charter summarized. Progressing scim 2.0 into an I-D. Is there interest in polishing this up or move to the next version.
• How much can you change it and still be considered v2.0? Does the charter today allow doing piecmeal update?
• Do we go towards 3.0 or address the 20+ topics outlined in the charter?
• Showed slide detailing all the work proposed in the charter. Doesn’t believe there is a conveinent way to do this in 2.0. There is a git repo with xml versions of the schema and protocol APIs. Will track as github issues. Echo issues to scim mailing list.
• Getting to discussion is the objective. I.e. either cut or resolve issues with existing standards. Some concepts are outdated.
• E.g., basic auth, passwords, photos, open to other concepts to cut
  [dz] - Slide - X Y Problem - are some concepts useful but outside the scim 2.0 content?
• is WG targeting v2.0, v.next or both?
• recap - (a) how big of changes can we make (b) bigger changes? © do we push back schema/protoc., milestones to wait for use cases?
  [pl] - Paul Lanzi - We should do the right thing. The more we incorporate into the use cases the better the outcome will be.
  [ja] - When exploring core schema, there are lots of questions e.g. do we keep passwords etc… If we break them out discretely then it becomes a bigger thing than needs to be. Looking to put a bow on 2.0. But need to drive forward on 3.0.
  [ph] - photos is just a URI, there is no need to import into ???
  [dz] - Problem with photos is communicating a URL then server needs photo on hand to process it. How does server retrieve image? Pulling the image everytime isn’t feasible. SaaS implementors want to store pic in their service to optimze latency. This approach isn’t possible in schema spec.
  [hjh] - Hans Jorg Happel - Identity providers provisioning SaaS would not appreciate major breaks / interoperability changes. Is there helpful guidance on or overview of UC that are alredy implemented?
  [ncw] - I think in the BOF there was a discussion of some proposed areas
  [pd] - There is a question on UC that were new that characterized as schema extensions. We have a starting point for that overview.
  [ncw] - We used the term ‘modernizing’ to describe schema extensions.
  [ncw] - The response is there was consensus from VI that inventors wwanted to choose how to solve the problem.
  [dz] - There’s lack of adoption of photos - Is the current standard fleshed out enough to be adopted? However, the 3rd bullet point was that schema and protocol should be delayed until UC are fleshed out so we know what schema/protocol work is needed.
  [ncw] - Need to look at the charter. The schema and protocol could be done in parallel.
  [dz] - Some of it can be done in parallel, but need clarity on 2.0 or v-next. 3.0 is a placehodler for v-next.
  [lj] - This is 3.0 (next) since v2.0 is already completed. We can’t break backward compatibility. Client implementation considerations should be first - need to get feedback from the community. Don’t push into core protocol if you don’t need to.
  [el] - I agree with lj about having an issue tracker will help. The more important thing is to understand what it looks like more than what version is what. Bigger choice is full change vs incremental. I disagree with lj (nitpick) - for core protocols what needs to be there vs. extensions? ot sure SCIM is perfectly extensible. Should be clearer about how to fully normalize for example. At the time SCIM first came out it was needed to be done so implementation could happen, now we have the luxury to spend time.
  [ja] - thanks for feedback, we want to do what’s right for the standard, there are areas that are interesting, there is this notion of single source of authority, part of the discussions are, should a Service Provider report back which attributes they won’t accept? If the server thinks phone number is authoritative, they may not accept phone number from a client. Move closer to an identity profile that is comes from multiple places, there is overlap, great to get feedback.
  [ncw] - Given the guidance, you could put a rough draft together then a call for adoption. The added detail will give people something concrete. The next VI or F2F the call can be made.
  [dz] - We’re at the end of the time.
  [ncw] - We keep bringing the mic back and forth, some people can’t hear. Next up is Phil with scim events, but having audio difficulties.
  [ph] - Nancy will read it.
  [ncw] -

Security Events Profile

[ncw] - What is a profile? and what are the security events?

• Security event token [“https://tools.ietf.org/html/rfc8417”|RFC 8417] - specialized use of JWT, a profile was developed, a common spec called “set” was created. We wanted JSON message that could be signed / encrypted.
• What is an sec-event and why is it different?
  • A set of signed statements delivered asynchronously.
  • In scim protocol relies with requester, in set control lies with the receiver
  • Coordination needed to link activities. In an event system the local action can be coordinated with external events.
  • 8417 is the event token RFC - hoping to something working shortly
  • 8935 - allows a publisher to post an event.
  • 8936 - allows http requests to post events.
  • They don’t require set publishers to hold long term state.
  • When event is acked it can delete its state - long polling.
  • Some publishers have 100K+ receivers hence maintaining past events doesn’t scale.
  • SET delivery has implementation issues - NCW will take over
    [ncw] - Showed slide on shared signals and events work (https://openid.net/wg/sse).
• there are two schemas (a) RISC and (b CAEP “cape” - WG interest in CAEP.
• Cisco implemented ref implementation at “sharedsignals.guide”
• Four events shown on slide.
  • Svc req
  • context update
  • policy update
  • remediation
• In scim the major UC is (a) domain based replication (b) Coordinated Provisioning
• Cited RFC7644
• No raw data is held, recvr can mark stale and take action, rcvr can do reconcillation on two-stage exchanges.
• If replication isn’t the primary objective then a lot of state can be omitted.
• Rcv’r can wait to do reconsilliation by marking rsrc stale.
• Alternative approaches creats some unique problems (outlined in slides)
• Slide showing sequence diagram of replication event handling. (needs to scale to 100x receivers)
• Slide showing seq. of two step reconcilliation approach.
• Security has high-level events that are somewhat duplicates Open-ID, but identifiers are stable scim identifiers while shared signals approach are less stable. Need to discuss goals.
• Scim is a profile of http, if we support this then scim messaging (RFC 7240) would be a no-brainer. Looking for feedback
• Scim uses attributes (slide showing SET Event Claims and Scim Events Claims) - compare / contrast
• toe is important because if events get out of sequence, toe can be used to reconstruct the correct sequence
• Slide on Subject Identifiers - CAEP/RISC use comlex subject identifiers - supports complex semantics
• SCIM profile uses SCIM ID and externalID as agreement on how to idenify a SET subject
• Slide showing example JSON profile
• Slide showing defined events
  • Feed Mgmt - Add/Remove subject to a feed
  • SCIM Api events - Create, Put, Patch, Delete
  • Signals - AuthMethod, pwdReset
  • Misc - AsyncResp
• Slide showing Delivery mechanisms
  • Two patterns for delivery
  • message buses become convenient because a bus can implement infinite event recovery, the bus takes care of delivery and fault tolerance. Can act as auditable record over time
  • Push/Pull for point-point
• Slide on Out-of-Scope items
  • how receivers should act
• the breakthrough of SET are to avoid prescriptions
  [ncw] - We have 5 min remaining - Questions?
  [tc] the statement around cmds is important - concern is that if you take a dependency you are leaning on ???
  [lj] - Echo suggest to just signal something is happened and let others take care of what happens next. Access model, security is affected. Can we discuss as the WG whether to keep things simple
  [tc] - If starting from a white sheet of paper then limit signaling on access control, security etc… worried about implementabiity. Can we allow scim client to figure it out?
  [tc] - scim is authoritative - concern over something that isn’t authoritative (SSE) in one endpoint and something that is (SCIM) in the other endpoint
  [ncw] - could be a case of clarifying the use case - soliciting more feedback over the mailing list. Other orders of business?
  [ncw] - Thank You - Does the WG want to continue with VI every six weeks?
  POLL : hands raised=14 , hands lowered=5 , total=20
  [ncw] - move poll to mailing list to ensure consensus.
  Session ended 4:30