[Openid-specs-risc] Today's meeting notes

Atul Tulshibagwale atultulshi at gmail.com
Wed Mar 9 01:23:53 UTC 2022


Hi all,
Here are the notes from today's meeting (also stored here
<https://github.com/openid/sse/wiki/WG_Meeting-2022-03-08>):

Agenda

   - Possible cyber security applications of SSE
   - Review Shayne's updated Stream ID proposal
   <https://github.com/openid/sse/issues/4#issuecomment-1057127339>
      - 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

<https://github.com/openid/sse/wiki/WG_Meeting-2022-03-08#attendees>
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)

<https://github.com/openid/sse/wiki/WG_Meeting-2022-03-08#notes>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
      <https://datatracker.ietf.org/doc/draft-hunt-scim-events> 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 <https://www.first.org/> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20220308/bb96bf9c/attachment.html>


More information about the Openid-specs-risc mailing list