[Openid-specs-risc] Meeting notes

[Atul Tulshibagwale]

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

Attendees:

   -

   Atul Tulshibagwale (Google)
   -

   Shayne Miel (Cisco)
   -

   Josh Matz (Cisco)
   -

   Hazel Kennedy (FCDO)
   -

   Tim Cappalli (Microsoft Identity)
   -

   Adam Goodman (Cisco)
   -

   Asad Ali (Thales)
   -

   Nancy Cam Winget (Cisco)


Agenda:

   -

   Create versus update: Should Updating a Stream's Configuration create a
   new stream if one is not present?
   -

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

   Does Removing a Stream's Configuration remove the stream or just the
   config? Should it revert to some default config? Does it also delete the
   subjects and events for that stream?
   -

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

   Wildcard subjects
   -

   RISC profile spec: Start OpenID Review?


Notes:

RISC:

   -

   We need to fix the subject format in two of the examples in the RISC
   profile spec
   -

   Everyone should read through the RISC profile spec and provide any more
   feedback


Add Create to Update Stream?

   -

   Adding a “stream create” method may or may not require broader changes
   to the API
   -

   If the endpoints are dictated by one’s identity as a tenant, then we can
   assume the stream already exists
   -

   Can a receiver have multiple streams? If so, then a “create” makes sense
   -

   When do you use a create versus an update
   -

   In the RISC case, we assumed the stream as something that always existed
   -

   The stream was considered a property of the relationship between the
   Receiver and the Transmitter
   -

   Current model is to have one stream between a Transmitter and a Receiver
   (as identified by the authorization token)
   -

   The audience claim in the SET is specified as a property in the
   Transmitter config
   -

   Do we need a way to specify the audience?
   -

   If the audience is determined by the authorization token used in the Get
   Transmitter Configuration Metadata method, then is the audience value
   derived from the client ID?
   -

   Receiver cannot specify the audience claim because it would be a
   security issue
   -

   Should there be some customizability in the audience value?
   -

   Is there a scenario that the Transmitter is not an OAuth provider? OAuth
   is a recommended way of authorizing the SSE API, but not required
   -

   Should OAuth be recommended? Can the spec not recommend any particular
   authorization method?
   -

   How does the Receiver discover the authorization method used by the
   Transmitter?
   -

   Does the “Get Transmitter Configuration Metadata” method require
   authorization? If this call is authorized, then the Receiver will need to
   know the authorization method
   -

   Authorizing the GET method is only required for Transmitters that need
   to customize the metadata to each tenant
   -

   How does the Receiver discover the Transmitter? OIDC uses the metadata
   from the well-known endpoint. OAuth2 doesn’t have something like that.
   There needs to be prior knowledge of the AS in OAuth2
   -

   If the Transmitter Configuration Metadata GET requires authorization,
   then there is no way right now for the Transmitter to specify the
   authorization method
   -

   Should the fact that there can be different authorization methods
   dictate that there be a stream ID? Any authorization method has to identify
   the caller, or the resource that they’re calling about.
   -

   One other aspect: From an auditing standpoint, if we need to correlate
   the stream, then in the absence of a Stream ID, how do we identify the
   stream?
   -

   The endpoint URL (if unique to each receiver) can identify the stream.
   The spec lets one use path components in the transmitter configuration, so
   it enables identifying the stream uniquely between a Receiver and a
   Transmitter
   -

   Do we need multiple streams between a Transmitter and a Receiver? We may
   want to separate RISC events and CAEP Events, for example.
   -

   Another use case: Data sovereignty. If one needs to make sure that EU
   events go to the EU stream and US events go to the US stream. This would
   necessitate two streams between the same Receiver and Transmitter
   -

   Conclusion: We need a create method to support all these use cases
   -

   Now we need to identify streams etc.
   -

   There is a Remove Stream Configuration method, but it isn’t clear what
   it does. Does it completely destroy the stream? Does it remove all
   subjects? We need to clarify the semantics, especially in the light of
   adding a Create.
   -

   Implementers could create a stream by default if they wanted to
   -

   Do we need a “List Streams” method? Probably yes.
   -

   Would this be a new version of the spec? It would probably just be a new
   implementer’s draft, because the spec is not final yet


Read-only Attributes in the Update method

   -

   If the read-only values are not included, then the update can succeed.
   -

   If the read-only values are included and they match the existing values,
   then the update can succeed
   -

   If the read-only values are included and they do not match, then the
   update must be rejected

Scheduling:

   -

   We need to switch temporarily back to a weekly schedule. We can skip the
   call on Nov 30th, but then do a call on Dec 14
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20211116/8ec16fd1/attachment-0001.html>