[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