[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Hi all,
Here are the notes from today's meeting. They are also stored here
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20230905>:

Thanks,
Atul

--

<https://sgnl.ai>

Atul Tulshibagwale

CTO

<https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
<atul at sgnl.ai>

WG Meeting: 2023-09-05
<https://hackmd.io/bXJwt6L3TAyajjH0-U6Fwg?view#Agenda>Agenda

   - https://github.com/openid/sharedsignals/pull/108
   - https://github.com/openid/sharedsignals/pull/109
   - https://github.com/openid/sharedsignals/pull/101
   - https://github.com/openid/sharedsignals/pull/87
   - How do we make new kinds of events available?
   - SSF Service general reference instead of Transmitter / Receiver

<https://hackmd.io/bXJwt6L3TAyajjH0-U6Fwg?view#Attendees>Attendees

   - Atul Tulshibagwale (SGNL)
   - Shayne Miel (Cisco)
   - Phil Hunt (Independent ID)
   - Erik Karlinsky (Okta)
   - Apoorva Deshpande (Okta)
   - Andrii Deinega()

<https://hackmd.io/bXJwt6L3TAyajjH0-U6Fwg?view#Notes>Notes
<https://hackmd.io/bXJwt6L3TAyajjH0-U6Fwg?view#Stream-ID-uniqueness-PR>Stream
ID uniqueness PR <https://github.com/openid/sharedsignals/pull/108>

   - (Atul) Should we clarify that the uniquness is per Transmitter?
   - (Phil) Should we say uniqueness per “SSF Service”
   - (Atul) A Receiver cannot guarantee uniqueness if it connects with
   multiple Transmitters
   - (Shayne) We cannot generalize Transmitter / Receiver to “SSF Service”
   because there are some things each one can do that is unique
   - (Erik) Context: Can a Receiver have the same stream ID from multiple
   Transmitters
   - (Shayne) That was an ambiguity in the spec. The intent was to specify
   uniqueness across all streams in a Transmitter
   - (Phil) There are many places in the spec that could need to be changed
   if we have to add language that is specific to Transmitter or Receiver
   - (Shayne) Can we move this dicussion as a separate topic?

<https://hackmd.io/bXJwt6L3TAyajjH0-U6Fwg?view#format-PR>format PR
<https://github.com/openid/sharedsignals/pull/87>

   - (Shayne) Please review

<https://hackmd.io/bXJwt6L3TAyajjH0-U6Fwg?view#events_delivered-is-not-a-subset>
events_delivered is not a subset
<https://github.com/openid/sharedsignals/pull/109>

   - (Apoorva) Phil raised this issue the last time

<https://hackmd.io/bXJwt6L3TAyajjH0-U6Fwg?view#Decoupling-SSF-and-OAuth>Decoupling
SSF and OAuth <https://github.com/openid/sharedsignals/pull/101>

   - (Atul) I have open questions about the OPRM spec on the OAuth mailing
   list
   - (Apoorva) should we remove this part entirely from the metadata
   - (Atul) I’m OK with removing OAuth references from the metadata
   - (Atul) Should authorization_schemes simply be a list of URNs?
   - (Apoorva) Should we have some admin visible field other than URN that
   we have in the metadata?
   - (Apoorva) Where is the documentation when a specified scheme does not
   map to an RFC?
   - (Shayne) Then should the Transmitter have out of band mechanisms to
   specify to Receivers
   - (Apoorva) As long as there is an understanding between the trusted
   parties

 "authorization_schemes": [
      {
        "spec_urn" : "<urn>"
      },
      {
        "spec_urn" : "<urn2>"
      }
]


   - (Phil) Do we want to be able to use OpenID client relationship in
   configuring SSF to provide capabilities such as logout?
   - (Apoorva) I think that fits within these plans as a use case
   - (Andrii) OpenID Connect can use only front channel for initiating
   logout from an RP to an OP, and the front channel is unreliable by its
   nature. The SSF spec is exciting for this as a use case.

<https://hackmd.io/bXJwt6L3TAyajjH0-U6Fwg?view#How-do-we-make-new-kinds-of-events-available>How
do we make new kinds of events available?

   - (Shayne) Do we want an IANA registry?
   - (Phil) The security events committee decided against a registry in
   favor of URNs that could uniquely identify the event type.
   - (Apoorva) OpenID logout is a command, not an event
   - (Phil) Disagree. It is a statement of some event that occurred.
   Otherwise, there are arguments that “you can’t tell me what to do”.
   - (Shayne) Can we at least provide links to public event documentation
   from the SSF docs?
   - (Phil) There are discussions with SCIM about registering events in IANA
   - (Apoorva) Do we need to switch event identifiers to URNs instead of
   URLs like they currently are in RISC and CAEP?
   - (Shayne) Maybe we should make the event identifier a URI so it can be
   either URL or URN
   - (Shayne) Either way, we should make it clear in the spec how one might
   create new kinds of event
   - (Phil) A “best practices” section would be nice for several things

<https://hackmd.io/bXJwt6L3TAyajjH0-U6Fwg?view#SSF-Service-general-reference-instead-of-Transmitter--Receiver>SSF
Service general reference instead of Transmitter / Receiver

   - (Phil) Trouble when implementing because spec doesn’t recognize that
   you can be both a Transmitter and Receiver
   - (Apoorva) Saw the same thing. Receiver config is completely skipped in
   spec.
   - (Phil) Problems:
      - If doing PUSH, Receiver has to be set up first, then Transmitter
      has to be connected
      - If doing POLL, Transmitter has to be set up first, then Receiver
      has to be connected
   - (Apoorva) It is hard for customers to know how to set up a Receiver
   - (Apoorva) We don’t mention when is the right time to start transmitting
      - (Phil) This is related to the issue about when does the stream start
      - (Shayne) Maybe a “start the stream” event, like the verification
      event

<https://hackmd.io/bXJwt6L3TAyajjH0-U6Fwg?view#Action-Items>Action Items

   - Apoorva to clarify scope of uniquness to be per transmitter
   - Apoorva to update PR#108 to have more normative language
   - Phil to talk to IANA about setting up an OpenID/SSF namespace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230905/9b99dea2/attachment-0001.html>