-
Notifications
You must be signed in to change notification settings - Fork 14
WG_Meeting 2022 02 15
- Atul Tulshibagwale (SGNL)
- Stan Bounev (VeriClouds)
- Joshua Matz (Cisco)
- Martin Gallo (SecureAuth)
- Shayne Miel (Cisco)
- Randie Pathirage (WSO2)
- Tom Sato (VeriClouds)
- Ravi (VeriClouds)
- Tim Cappalli (Microsoft)
- Updates on Shayne's proposal for Stream IDs
- SCIM Proposal discussion
-
Calling "list streams" on the default stream does not make sense, so we should rename the endpoint to "list named streams"
-
Why do we need a default stream? It is to avoid the receiver to go through extra hoops to setup a stream
-
Proposal: Create a specific named default stream
-
Does the Receiver assign the stream id? We should have the Transmitter define the stream Id
-
Do we always have a default stream? The Transmitter could decide
-
Receivers could do a list call to find out if there's a default stream
-
Transmitter configuration metadata field that indicates whether the transmitter always has a default stream
-
Well known configuration does not have authentication
-
Discovery mechanism needs to be consistent. If it doesn't say that you must not require authentication to fetch the metadata, then we should modify the standard to say so.
-
We should require receivers to create a stream every time. We should call out the Google implementation's incompatibility
-
We should be clear about which endpoint creates versus which one updates. We should go with the REST model
-
We should drop the language about "named stream" and "default stream" because all streams are named (i.e. there is no default stream)
-
Transmitter should generate the stream Id as a result of the create call
-
Do we want the Transmitter to be completely discoverable?
-
Well known URLs should be open (must not require authentication)
-
Shayne will update his proposal to reflect these changes
-
Use https://xml2rfc.tools.ietf.org/ to convert xml to txt and html, and manually update those files
-
Any other comments: woof woof!
-
Should we have a discussion around headless discovery so that we can specify the auth scopes required in the discovery process? Tim to create an issue to track this
-
Please review the proposal to figure out if it's a good use case for using SSE in SCIM