# WG Meeting: 2024-06-04
## Agenda
- New issues review
- [Remove cause time](https://github.com/openid/sharedsignals/issues/178)
- Review pending items for ID-3
- Events Specs "Democratization"
- Interoperability Event in December
- SSF Japan meeting follow up
- (Nick) Is anything being done to check the verification status of an email address if it is present in an SSF event?

## Attendees
- Atul Tulshibagwale (SGNL)
- Shayne Miel (Cisco)
- Nick Wooler (Cisco Webex)
- Jen Schreiber (Workday)

## Notes
### RISC event example in SSF spec has an unknown field "Cause-time"
- (Atul, Shayne) We should remove it

### Pending Items for ID-3
- [PR 172](https://github.com/openid/sharedsignals/pull/172)
- (Atul) I agree that it sounds like a "MUST" is a better word for checking the issuer of the events received by a receiver
- (Jen) I agree
- (Jen) The SET spec [specifies](https://datatracker.ietf.org/doc/html/rfc8417#section-3) that any profile must specify to validate the SET
- (all) Reading the "validation" subsection together
- (Jen) What does "semantically valid" mean in our case?
- (Atul) E.g. if a stream requires subjects to be explicitly added, then semantically valid could mean a received event has a subject that was added
- (Jen) Can we have unsigned SETs?
- (Atul) JWTs allow alg:none
- (Jen) If that's true, then we need not specify signature verification
- (Jen) Do we specify that SETs should be signed?
- (Atul) I believe SETs MUST be signed if we are using Push delivery, but the spec probably doesn't say that
- (Atul) Did we add language recently to require sender authentication?
- (Atul) What does it mean to verify the `iss` value at the time of stream creation? If I have a transmitter located at `transmit.mycompany.com`, but the `iss` value is `https://mycompany.com`, is that valid?
- (Shayne) We currently don't seem to tie the `iss` to the URL of the issuer. We should update the PR to say that.
- (Jen) Should it match exactly?
- (Shayne) I think it has to
- (Atul) What if the Transmitter Configuration Metadata has the `iss` value as `saascompany.com`, but upon authentication by a specific tenant, the issuer in the stream becomes `tenant1.saascompany.com`. Should that work?

### SSF Japan meeting follow up
- (Shayne) Naohiro mentioned that interest from RPs like Webex was important for adoption in Japan
- (Nick) We need to know which IdPs would be interested if Webex were to implement.
- (Nick) Webex is very interested in SSF along with SCIM
- (Shayne) Let's follow up offline

### Is anything being done to check the verification status of an email address if it is present in an SSF event?
- (Jen) This sounds like it is a bit out of scope of SSF
- (Nick) Has there been any discussion about it?
- A verified email being used by the IdP is known at the time the event is created
- There may be something in the registration of the stream, that there is some trust established about the subjects
- From a Webex perspective, if that identity is being used for some purposes, a verified email address is important
- A stream not having verified email addresses could be harmful
- (Jen) Is there anything in the security considerations?
- (Atul) We could define a new subject type that has a "verified email" type
- (Jen) What does "verified" mean?
- (Nick) This is something like SCIM
- (Nick) Given what has happened in a few incidents recently, creating users with email addresses in the enterprise without verifying, social logins were exploited to take advantage of the trust in the enterprise account
- (Nick) Perhaps it's just a note in the security consideration that the email address may not be verified
- (Shayne) Is that just a conversation that needs to happen between a Tx and an Rx? The Rx could say to the Tx to only send it verified email addresses
- (Nick) That could be a way ot handle it
- (Atul) The spec currently is incapable of indicating whether an email is verified or not, and an IdP with a mix of user population will not be able to identify that in events today
- (Shayne) When an event receiver adds a subject to the stream, it can indicate whether the subject is verified or not. Does it address the problem?
- (Jen, Shayne) However we need the Tx to identify the email as verified or not
- (Nick) How does this affect the value chain, and fit into the overall architecture
- (Atul) This could be raised to understand whether the subject is verified or not
- (Atul) This could be something we tackle post ID-3 or post final 1.0.
- (Shayne, Nick) This needs a bit of discovery, how many Transmitters really have a problem?

## Action Items
- Nick to create an issue to track the "verified email" issue
-