[Openid-specs-risc] openid/sharedsignals: Comment created on issue 282

[github at oidf.org]

openid/sharedsignals event

Issue Comment created on issue 282
Issue Title: Provide Guidance and Examples for Edge Cases in Complex Subject Matching
https://github.com/openid/sharedsignals/issues/282

Comment: Shoot. I started adding examples for this and realized that we should probably treat array values as an ANY match (i.e. if the event's value matches any of the values in the array that the Receiver added, the event should be sent). Here is an example: The Receiver has added the following subject to their stream: ~~~json { "format": "complex", "user": { "format": "aliases", "identifiers": [ { "format": "email", "email": "jdoe at example.com" }, { "format": "email", "email": "john.doe at example.com" }, { "format": "phone_number", "phone_number": "+12065550100" } ] } } ~~~ The Transmitter has an event to broadcast with the following subject: ~~~json { "format": "complex", "user": { "format": "aliases", "identifiers": [ { "format": "email", "email": "jdoe at example.com" }, { "format": "phone_number", "phone_number": "+12065550100" } ] } } ~~~ According to the matching rules currently described in the spec, the Transmitter SHOULD NOT broadcast the event over the Receiver's stream because the two aliases identifiers are not an exact match. But looking at this example, we would probably want to consider this a match. We would also want to consider the following a match ~~~json { "format": "complex", "user": { "format": "email", "email": "jdoe at example.com" } } ~~~ Doing this would be a major normative change, so I think we should wait until v2.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250717/46b2a8dd/attachment.htm>