[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Hi all,
Thanks to those who attended today's call. Here are the notes. They are
also stored here <https://hackmd.io/@oidf-wg-sse/wg-meeting-20230718>.

Atul

-- 

<https://sgnl.ai>

Atul Tulshibagwale

CTO

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

WG Meeting: 2023-07-18
 Comment
<https://hackmd.io/sZM6grzMSpuigi_6AI0TWw#Agenda>Agenda

   - Breaking change: endpoint_url is renamed to url
   <https://github.com/openid/sharedsignals/issues/79>
   - Stream Status and Error Diagnosis
   <https://github.com/openid/sharedsignals/issues/77>
   - Chattiness of github updates to the mailing list / Slack
   - (smiel) Recommendations for namespacing opaque IDs?
   - PRs review
      - “sub_ids” <https://github.com/openid/sharedsignals/pull/82>
      - Stream exists behavior
      <https://github.com/openid/sharedsignals/pull/50>

<https://hackmd.io/sZM6grzMSpuigi_6AI0TWw#Attendees>Attendees

   - Atul Tulshibagwale (SGNL)
   - Shayne Miel (Cisco)
   - Kyle Neuman (DirectTrust)
   - Apoorva Deshpande (Okta)
   - Steve Venema (ForgeRock)
   - Eric Karlinsky (Okta)
   - Peter Travers (Beyond Identity)

<https://hackmd.io/sZM6grzMSpuigi_6AI0TWw#Notes>Notes
<https://hackmd.io/sZM6grzMSpuigi_6AI0TWw#Breaking-Change---endpoint_url-is-renamed-to-url>Breaking
Change - endpoint_url is renamed to url

   - We need to fix the spec so that it continues to say “endpoint_url”
   instead of “url”, which was the breaking change introduced in a recent
   update to the draft

<https://hackmd.io/sZM6grzMSpuigi_6AI0TWw#Stream-Status-Error-and-Diagnosis>Stream
Status Error and Diagnosis

   - We should add “reason” to the GET Status response to address this issue
   - [Apoorva] Do we need to add subject in the stream status?
   - [Shayne] We already have the ability to add a subject in a Get Status
   request, but there are open issues of what happens when a subject within a
   paused stream is enabled?
   - [Apoorva] But do we have the ability to pause subjects?
   - [Shayne] Yes, the spec allows that
   - [Apoorva] But the method is “stream status”, not “subject status”
   - [Shayne] It’s about the status of the stream as it relates to the
   subject
   - [Atul] Is this an overkill? Can we drop the ability to have subjects
   in Stream status?
   - [Apoorva, Shayne] agree it seems like an overkill
   - [Steve] Is there a way of knowing whether a stream includes a subject
   or not?
   - [Shayne] Adding a subject / removing a subject is idempotent
   - [Steve] What if you didn’t want to add but wanted to know if it exists?
   - [Shayne] There was some discussion on explicitly not being able to
   list subjects in a stream for privacy / security reasons
   - [Peter] Should it be up to the Transmitter whether or not to respond
   to a query for a specific subject
   - [Steve] A list could result in a Denial of Service
   - [Atul] We could just have a query and not a list
   - [Steve] There is a trust relationship, so having a hostile receiver
   could mean bigger issues
   - [Kyle] Is the response meant to be computable? Or is it meant to be
   just informative
   - [Apoorva] The spec should not allow a “list” method, because it could
   lead to a brute force / other attacks
   - [Atul] Is this critical to have in the implementer’s draft?
   - [Steve] If the Receiver loses context of the stream, they may just
   have to rebuild the stream
   - [Atul] Adding this later may not break anything
   - [Shayne] Should we remove the ability to query status per subject in
   the current draft? (general agreement in the call)

<https://hackmd.io/sZM6grzMSpuigi_6AI0TWw#Chattiness-of-GitHub-Updates-on-Email>Chattiness
of GitHub Updates on Email

   - [Shayne] It’ll be good to filter for just important things like a new
   PR or new issue, but right now it is too noisy
   - [Steve] I noticed the “sub_id” PR because of the email updates
   - [Atul] Propose to keep the email updates until we submit for
   Implementer’s Draft review, and turn off after that

<https://hackmd.io/sZM6grzMSpuigi_6AI0TWw#Namespacing-of-opaque-IDs>Namespacing
of opaque IDs

   - [Shayne] How do we namespace opaque IDs. Let’s say we have device IDs
   from different sources (Zoom Client, Slack Client, etc.) - each one could
   be a different opaque ID, but there’s no way to tell which one we’re
   talking about
   - [Atul] Would you use the ‘iss’/‘sub’ instead of opaque in that case?
   - [Apoorva] Iss/Sub won’t still tell us whether it’s a UDID or some
   other format
   - [Atul] The URN in the “iss” value can be specific to the format
   - [Shayne] This gives me the information I need

<https://hackmd.io/sZM6grzMSpuigi_6AI0TWw#PRs>PRs

   - “sub_ids” <https://github.com/openid/sharedsignals/pull/82>
   - [Steve] The nomenclature seems a bit muddy, will comment on PR
   - [Shayne] One issue worth talking about: Do we need to update the call
   signatures of all endpoints? (e.g. Stream Updated, Verification, etc.) We
   could keep the endpoints the same
   - [Shayne] You could still respond with “sub_id” in the SET, but the
   request could still refer to “subject” (you’re adding a “subject”, not
   “sub_id”)
   - [Steve] Reviewing how we got here: sub -> subject -> sub_id
   - [Atul] The request parameter being called “subject” doesn’t cause any
   inconsistency or contradiction, so we can keep it that. Atul to make the
   change in the PR

<https://hackmd.io/sZM6grzMSpuigi_6AI0TWw#Implementer%E2%80%99s-Draft-timeline>Implementer’s
Draft timeline

   - [Atul] I’d like us to submit our draft for review by end of July

<https://hackmd.io/sZM6grzMSpuigi_6AI0TWw#Action-Items>Action Items

   - [Shayne] PR to remove the ability to query status of individual
   subjects
   - [Apoorva] PR to change url to endpoint_url
   - [Shayne] PR to add “reason” to the stream status
   - [Atul] Update sub_ids PR to revert to using “subject” in the requests
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230718/381fa536/attachment-0001.html>