WG_Meeting 2022 02 01

Attendees

• Atul Tulshibagwale (SGNL)
• Shayne Miel (Cisco)
• Stefan Duernberger (Cisco)
• Randie (WSO2)
• Tom Sato (VeriClouds)
• George Fletcher (OpenID Foundation)
• Nancy Cam Winget (Cisco, OpenID Board member)
• Martin Gallo (SecureAuth)

Agenda

• Intros
• Stream ID discussion
• Github transition
• Website content

Notes

Intros and Reintros

• George Fletcher involved in RISC way back when it first started

  • Community elected board member
  • Formerly with Yahoo, now with Capital One

• Randie interested in incorporating this spec into their IAM product

  • Randie works for WSO2

Stream ID Discussion

• Transmitter Metadata configuration does not include "event supported" or stream-specific info, so it may be unchanged with the addition of multiple streams.

• Shayne's proposal about multiple streams

• As Backwards compatible as possible

• In the Transmitter Configuration Metadata, add a "stream_types" section. Streams can be "default" or "named"

• A "Stream Configuration Object" contains a new member "stream_id" (optional, so if missing, it's the default stream)

• The Stream Configuration object is an optional argument to the configuration endpoint POST method

• Transmitter may respond with 409 if the stream_id specified in the configuration argument already exists.

• POST should not be for update, should only be used for CREATE (would be backwards incompatible)

• GET request to the Stream Configuration (7.1.2) is modified to add the stream_id (optionally)

• PATCH (new method) on Stream Config can be used to update the stream configuration (instead of the current POST)

• Current POST method used to update deletes the format if the format value is not specified in the input. New PATCH method should leave the format value unchanged

• Sending readonly attributes to the create method (POST) should still work if the attributes match the stream's configuration, and fail if it does not.

• Sending incorrect readonly attributes to PATCH should result in status 400

  • Receivers MAY do a "GET" upon receiving a 400 and include the right values, or they MAY omit the readonly values in the request.
  • Receivers SHOULD first verify the readonly attributes in a PATCH success response if they have omitted the values in the request.
  • Should the Transmitter ignore the readonly values? Receivers could still make sense of the response by reading the readonly values in the response. We could go either way.
  • Is the problem that there is a mix of readonly and read-write fields? Should we do it such that PATCH only takes the read-write values
  • The default expectation is that the Receiver always sends the configuration object. We should have a consistent response to that. It might be easier for the Transmitter to ignore the readonly fields, and if needed the Receiver can check the response for matching values
  • How do we give the developer the most consistent and easiest experience with this API
  • We should review industry best practices before deciding on this.

• DELETE on a the default stream resets it to its default state (needs discussion)

• All other endpoints get an optional "stream_id" parameter

• Shayne to share the document. Use the Github discussion board

• Does MS support SSE in production? Not that we know of as of this time.

Github transition

• Everyone seems OK with it, so we will switch the repository link to Github
• Who can approve Github requests? Probably co-chairs. Tim to confirm

Website discussion

• General contents of Atul's proposal are good, but we need to fine tune it with the target audience in mind
• Should we have introductory content for non-technical people. E.g. what is a Transmitter or Receiver
• Tom can produce two videos if required
• Tom to propose an updated website layout
• Cisco won't mind using their video in the SSE page
• We should have some information about SSE for product or business owners. This content should articulate the value of SSE and why it matters to the business audience