[Openid-specs-risc] Call notes, and an important call out

[Atul Tulshibagwale]

Hi all,
We are faced with an issue that the proposed spec that is currently in
review does not unambiguously address the situations when:

   1. The subject (in an event or an "add subject" or similar call)
   contains an element of type "ip_addresses" with more than one IP address in
   it, and it needs to be matched with a set of IP addresses that is a subset
   of those specified.
   2. The subject contains an element of type "alias" with more than one
   alias in it, and it needs to be compared with a subject that has a subset
   of the specified aliases.

The ambiguity comes from:

   - RFC9493
   <https://www.rfc-editor.org/rfc/rfc9493.html#name-aliases-identifier-format>
   not specifying what constitutes an exact match of aliases
   - Section 3.5.3
   <https://openid.net/specs/openid-sharedsignals-framework-1_0.html#name-ip-addresses-subject-identi>
   of the draft not specifying how to match arrays of IP addresses
   - Section 8.1.3.1
   <https://openid.net/specs/openid-sharedsignals-framework-1_0.html#name-subjects>
   having a sentence that says "two (simple) subjects match if they are
   exactly identical"

On the call, we agreed that this could be misinterpreted in practice, but
it is unlikely. The issue raised about this
<https://github.com/openid/sharedsignals/issues/282> (which started this
discussion - thanks Vatsal Gupta) says "it could lead to inconsistent
logic", indicating that this was a theoretical question rather than an
implementation blocker.

Since clarifying this will require normative changes to the draft spec, and
as a result restart the review period, we thought it would be OK to
highlight this as an open issue in the call for votes at the end of the
review period. We will mention that we need to fix it after the final spec
is released. This will lead to incompatibility with any implementation of
the final spec that differs from the changes we intend to make.

I'd like the working group to provide their opinions on this email thread
so that we can make a decision regarding this in the next meeting.

The notes for today's call are below. They are also stored here
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20250722>.

Thanks,
Atul

-- 

 Atul Tulshibagwale

 CTO

  <https://www.linkedin.com/in/tulshi/> <atul at sgnl.ai>
---
WG Meeting: 2025-07-22 <#Agenda>Agenda

   - Review / voting dates
   - Tentative interop at Authenticate 2025 (Carlsbad, CA, Oct 13-15)
   - Issue 282: examples for complex matching Issue 282
   <https://github.com/openid/sharedsignals/issues/282>

<#Attendees>Attendees

   - Atul Tulshibagwale (SGNL)
   - Shayne Miel (Cisco)
   - Robert Gallagher ()
   - John Marchesini (Jamf)
   - Apoorva Deshpande (Okta)
   - Sean O'Dell (Disney)

<#Notes>Notes <#Review--voting-dates>Review / voting dates

   - Review period ends Sunday, August 10, 2025
   - Voting period begins: Monday, August 11, 2025
   - Voting period ends: Monday, August 25, 2025

<#Interop-at-the-Authenticate-Conference-2025>Interop at the Authenticate
Conference 2025

   - Interop resources
   <https://drive.google.com/drive/folders/1_VA6sUh8jXSUDbM9N_hPrCk6ik8OlwRN?usp=sharing>

<#Examples-for-complex-matching>Examples for complex matching

   - When I was going through the examples for complex subjects, with
   arrays and adding examples
   - But when I follow the language in the specs, "all fields in the
   complex subject must match"
   - If there are array values, then the implication is that a subset of
   the array values is not an actual match. This is probably not the behavior
   we want.
   - We will need a normative change to make this work.
   - If the receiver has registered an alias subject, and it has an ip
   address, and the user is identified by an email address, then doesn't the
   Transmitter need to send an event about that user?
   - (Atul) How to match a simple subject should be where the subject is
   defined
   - (Atul) rfc9493 should inform us on how to match it
   - (Shayne) 2 subjects match if they are identical is strong language and
   find it a hard way on changing this in a v1 but not v2.
   - (Atul) might leave this as an open issue and not one to address right
   now.
   - (Atul) IP Address subject types (Section 3.5.3) it does not tell you
   how to compare them and is problematic. A choice is needed now to change
   now or defer.
   - (Sean) My vote is defer.
   - (Atul) This is a clarity of spec issue and might be counter intuitive.
   - (Atul) How do we treat alias matching and the rules are not clear.
   - (Shayne) Most implementers don't use add subject so this is likely
   masked.
   - (Atul) We have rules on matching in 8.1.3.1 in the SSF Spec
   - (Atul) Events are about subject and matching is important
   - (Atul) Leaning towards not updating in V1 and will state that as it
   still being an open issue.
   - (Shayne) if we wait will it change anything in backwards
   compatibility? Wait to do it in V1 not V2?
   (Atul/Shayne) - Consideration on backwards compatibility are subject to
   implementations.
   (Atul) - So inform of normative changes in the voting period for voters
   to look at implementing forward with context. So you cant assume backwards
   compatibility.
   (Apoorva) - Why is this not a problem for receivers for events they do
   not understand?

<#Action-Items>Action Items

(Shayne) - Will mention it in the notes when talking to Mike Jones that the
guidance will be offered in V2.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250722/cb804e6f/attachment.htm>