[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Hi all,
Here are the notes from today's call. Also stored here
<https://github.com/openid/sse/wiki/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)

<https://github.com/openid/sse/wiki/WG_Meeting-2022-02-01#agenda>Agenda

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

<https://github.com/openid/sse/wiki/WG_Meeting-2022-02-01#notes>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
   -

   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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20220201/66aab66f/attachment-0001.html>