WG Meeting: 2023-07-18

# WG Meeting: 2023-07-18 ## 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) ## Attendees - Atul Tulshibagwale (SGNL) - Shayne Miel (Cisco) - Kyle Neuman (DirectTrust) - Apoorva Deshpande (Okta) - Steve Venema (ForgeRock) - Eric Karlinsky (Okta) - Peter Travers (Beyond Identity) ## Notes ### 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 ### 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) ### 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 ### 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 ### 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 ### Implementer's Draft timeline - [Atul] I'd like us to submit our draft for review by end of July ## 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