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

• 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

• Slack channel link: https://join.slack.com/t/oidf/shared_invite/zt-11hmgy0k2-ODFu15iyGuPMmInN3ch_7w

• 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 success response if they have omitted the values in the request.

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