[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Hi all,
Here are the notes taken in the call today. The notes are also in this doc
<https://docs.google.com/document/d/1ZFwJJDwwSBNKX35VObClC1ctMbMMuHJtr5qY-7xsLW8/edit?usp=sharing>
.
Call on Nov 9, 2021

Attendees:

   -

   Atul Tulshibagwale (Google)
   -

   Shayne Miel (Cisco)
   -

   Stan Bounev (VeriClouds)
   -

   Josh Matz (Cisco)
   -

   Martin Gallo (SecureAuth)
   -

   Adam Goodman (Cisco)
   -

   Tim Cappalli (Microsoft Identity)
   -

   Chamath Samarawickrama


Agenda:

   -

   Clarify PATCH/PUT instead of POST
   -

   Socialization effort updates
   -

   Closed loop verification
   -

   Wildcard subjects
   -

   RISC draft review process


Notes:

Clarify PATCH  / PUT instead of POST

   -

   Atul to review draft and identify places where we should use PATCH / PUT
   instead of POST, according to aip.dev. Tim recommends changing stream
   status update and stream configuration update methods
   -

   Should Add Subject and Remove Subject also have the same changes? The
   verbs used in the description of the event indicate a POST and DELETE
   -

   Does calling “Update Stream Configuration” create the stream, so if it
   were a PUT, that would be clear.
   -

   Should we clarify the two use case possibilities - in the case where
   there is tenant-level authorization, you can create the stream by calling
   Update Stream Configuration
   -

   If we’re revisiting this part, we should also revisit the read-only
   properties of the stream that are today a part of the update method
   -

   Some of the multi-tenanted / single-tenanted behavior is not clear from
   the spec, so we should clarify that
   -

   We should schedule a call this time next week and request Annabelle to
   attend to clarify the use of “create” versus “update”
   -

   Agenda items:
   -

      Create versus update
      -

      What text should we have to describe the single-tenant versus
      multi-tenant use cases
      -

      How should we handle read-only attributes in the update method
      -

      Wildcard subjects

Socialization Update:

   -

   At the meeting after the Authenticate conference (attended by Vittorio
   (Okta/ Auth0), Darell (Ping), in addition to regular members). The
   consensus was that there needs to be an easy way to test implementations
   for Transmitters and Receivers. So we should publish reference code for
   Transmitters first and then Receivers. We are looking for companies that
   can volunteer to provide such implementations.
   -

   Update from Microsoft: Resourcing is not looking good for the reference
   implementation, but no decision yet.
   -

   Please reach out to Stan Bounev if you would like to participate in
   building the reference implementation
   -

   Upcoming events
   -

   Home page should be re-written to have revised position re: Webhooks for
   the SSE Framework, add Annabelle’s presentation. Please mail more
   suggestions to the list


Closed-loop Verification

   -

   In setting up a stream, should the Transmitter send a token to the
   Receiver, which the Receiver sends back. This forces the Receiver to parse
   the token and send back something that proves they have been able to
   receive the token
   -

   This will be only during stream setup
   -

   Tim to come back with some more details


Wildcard Subjects

   -

   Use cases: Say the Receiver wants to get all revocation events. By
   omitting the subject identifier specific to a user or device
   -

   Future use cases could misinterpret a general subject (e.g. OU or
   Tenant). Instead if we specified the subject as “Tenant X, User *”. For
   example, how would you request events for subjects that are only users, not
   devices.
   -

   Instead of “*”, we could specify the subject identifier type (e.g. user)
   and not specify a value to indicate “all matching users”
   -

   We need input from someone who is more familiar with the IETF subject
   identifiers spec to understand whether they have thought of this in that
   spec.


Review process for RISC spec:

   -

   We need to start a new review process for the RISC spec implementer’s
   draft.
   -

   Atul to create the new drafts and request Mike Jones to start a new
   review process
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20211109/ab8c1e46/attachment-0001.html>