WG_Meeting 2022 03 08

Agenda

• Possible cyber security applications of SSE
• Review Shayne's updated Stream ID proposal
  • Yes/no on making all read-only values in the stream configuration REQUIRED
  • Yes/no on PUT and PATCH for replacing and partial update (respectively) as is standard
    • Alternative is to use Google method of masking variables in the update call
  • Yes/no on adding aud to the arguments that create the stream
• VeriClouds SSE Transmitter Overview

Attendees

• Atul Tulshibagwale (SGNL)
• Stefan Duernberger (Cisco)
• Shayne Miel (Cisco)
• Jason Garbis (Appgate)
• Stan Bounev (VeriClouds)
• Tom Sato (VeriClouds)
• Nancy Cam-Winget (Cisco)
• Tim Cappalli (Microsoft)
• Rifaat Shekh-Yusef (Okta)
• Lee Tschetter (Okta)
• Gail Hodges (OpenID Foundation)

Notes

• Intro:

  • Jason: Chief Product Officer at Appgate - Also co-chair of Cloud Security Alliance - working on zero-trust. Excited about SSE - could be a way to tie ... see lots of potential.
  • Jason needs to sign the membership agreement.

• Shayne's proposal

  • What happens when a read-only value is supposed to be null?
  • PUT is to replace, PATCH is to update. What happens if there are missing read-only values in a PUT?
  • Do we need to support PUT? There is no way to set a value to "none" using PATCH
  • Versioning could solve the backward compatibility problem
  • The error response (4xx) could be used to force the client to do a GET
  • We at least need a version number in the Transmitter configuration (prefer that over putting it in the stream configuration)
  • SCIM supports versioning at a stream level, but we could do this in the future
  • We may have to support it at a metadata level, because some methods like "add-subject" may have a different signature for v1 versus v2, say.
  • We agree that we want versioning, so PUT can behave differently, but we can discuss how the versioning works separately
  • Do we need a distinct error code to force the receiver to do a GET? How would the transmitter know that it's a formatting issue from the receiver? We can have distinct error codes based on the parseability of the input (e.g. 422)
  • Missing read-only values should result in a 422 error code
  • What happens when the Receiver specifies a wrong value for a read-only attribute? It should return a 422 error code, because it is similar to a missing read-only value (incorrect input)
  • So we have decided that read-only values are required, and the Transmitter MUST provide them
  • How does SCIM do this? Answer: Not well! SCIM may need fixing here too.
  • 'aud' value in the arguments to create stream? It's OK for the client to specify, since the client may want different values at different times
  • How does the Transmitter respond if they get an unacceptable audience value? We need to discuss this separately
  • Is the intent that there are going to be different streams and part of the authorization / differentiation is going to come from the token and part of it is going to be from the audience value? Largely yes
  • The audience field is not changed by the Receiver, but it could be set in the stream creation, as per Shayne's proposal
  • The only way to change the audience would be to delete the stream and re-create it with a new audience value
  • We should discuss this in the next call

• Cyber-security applications of SSE:

  • Can SSE be used to address some of the cybersecurity concerns that are more urgent due to the current Russia-Ukraine conflict
  • Tom and Gail discussed this yesterday, Atul and Nancy provided some comments too. What does the working group think about this?
  • Are there any overlapping standards that provide similar capability as SSE? (Nancy mentioned STIX/TAXII, OpenIOC, IETF RFC 8600, OWASP)
  • Raw telemetry used to advice decisions of enforcement?
  • Cybersecurity is an active space, so anything we contribute could be very narrow
  • We should be open in the cyber-security community. Any information can be valuable to a cyber-security people
  • Phil Hunt put forward a profile in the SCIM WG that could leverage SSE
  • The SET (RFC 8417) that SSE uses is also defined in the IETF
  • Should we discuss this in the IETF? We should be doing more in the OpenID Foundation about cyber security. We should highlight the value that SSE can provide
  • STIX / TAXII and FIRST communities
  • Okta believes that cyber-security is an identity centric problem
  • We can do simple things like global session logout / termination that can have a big impact on improving security
  • Things are getting so granular that cyber-security is increasingly an identity problem
  • If there is work to be done in terms of standards crunching, how can we accelerate that in the face of the urgency we have
  • Can we have a hypothesis together in 2 weeks and discuss this with cyber-security experts?
  • Having some scenarios painted that show how this can work as a "central nervous system" in a cyber-security defense
  • Okta working on demos / proof-of-concepts that can be exciting to ISVs
  • Its a path to failure if the expertise is manifested in only 3 products, whereas other vendor products are not protected
  • We need to do both: We need to build a fabric that enable security vendors to share signals, and secondly continued education on cyber security - devSecOps and incident-response aspects that SSE can provide telemetry

• VeriClouds is releasing their SSE product, and they will reach out to members individually