<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
openid/sharedsignals event <br>
<br>
Issue Comment created on issue 282 <br>
Issue Title: Provide Guidance and Examples for Edge Cases in Complex Subject Matching
<br>
https://github.com/openid/sharedsignals/issues/282 <br>
<br>
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@example.com" }, { "format": "email", "email": "john.doe@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@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@example.com" } } ~~~ Doing this would
be a major normative change, so I think we should wait until v2.
</body>
</html>