# WG Meeting: 2023-07-11
## Agenda
- sub_id at the top level
- -standardized scopes / authorization server endpoint [Issue 74](https://github.com/openid/sharedsignals/issues/74)
-

## Attendees
- Atul Tulshibagwale (SGNL)
- Mike Kiser (SailPoint)
- Shayne Miel (Cisco)
- Steve Venema (ForgeRock)
- Apoorva Deshpande (Okta)
- Tim Cappalli (Microsoft)
- Phil Hunt (IndependentID)

## Notes
### sub_id at the top-level

[Phil]
- SCIM Events spec doesn't have to refer to SSF because it refers only to the "sub_id"
- There may be scenarios where you need to keep the event payload confidential (no spec for that yet)
- In CAEP / RISC you have subjects that are added or removed from the stream, so those can be the top-level "sub_id" claim, but other subject information (if needed) can be inside the event

- [Steve] Could JWE cover the event payload encryption?
- [Phil] It could be that the event has a claim that is JWE
- [Steve] Sometime back we had talked about just using TLS, and not needing encryption in any use-case
- [Phil] If we have a multi-hop environment, where you do not want to reveal the content of the event to intermediaries, then you may need encryption
- [Steve] So the motivation seems to be scaling. Have any of the implementers on this call run into this issue?
- [Phil] We just need to avoid getting into a situation where SSF is un-routable based on sub_ids
- [Shayne] Do we have a way of doing this in a less "breaking" way, e.g. adding "sub_id" at the top-level in addition to being in the event?
- [Tim] We need to make the change now, if we are thinking of it, because it will be harder to make the change later.
- [Phil] Having duplicate information is OK for now, especially if we are going to deprecate on of them later
- [Steve] We'd have to be very clear about which field takes priority
- [Apoorva] The subject duplication is going to remain for some time due to existing implementations
- [Steve] If people are already using "subject" in the event, and you are required to ignore any top-level claims that you don't understand, then won't it not break anything?
- [Apoorva] If "sub_id" get included in the SSF spec, then won't it be inconsistent with CAEP and RISC specs?
- [Atul] The top-level claim will be "sub_id", but the CAEP And RISC events reamin the same.
- [Atul] We should just remove the "required subject field in every event" language from the SSF spec
- [Atul] Conclusion: Add sub_id at the top-level, keep "subject" in events, but note that such usage is deprecated for new events being defined.

### Standardizing scopes
- [Apoorva] The current proposal is likely to break current implementations, so can we define it in a way that doesn't break existing implementations, e.g. by putting the new information in top-level claims

~~~ json
{
"issuer":
"https://tr.example.com",
"jwks_uri":
"https://tr.example.com/jwks.json",
"delivery_methods_supported": [
"urn:ietf:rfc:8935",
"urn:ietf:rfc:8936",
],
"configuration_endpoint": "https://tr.example.com/ssf/mgmt/stream"
}
"status_endpoint":
"https://tr.example.com/ssf/mgmt/status",
"add_subject_endpoint":
"https://tr.example.com/ssf/mgmt/subject:add",
"remove_subject_endpoint":
"https://tr.example.com/ssf/mgmt/subject:remove",
"verification_endpoint":
"https://tr.example.com/ssf/mgmt/verification",
"critical_subject_members": [ "tenant", "user" ]
"supported_scopes": {
"poll_endpoint": ["scope1", "scope2"],
"status_endpoint": ["scope1"],
"configuration_endpoint": ["scope3", "scope4"]
},
"authorization_servers": [
{ "scopes" : ["scope1", "scope2"],
"servers" : [ "https://server1/.well-known", "https://server2/.well-known"]
},
{
"scopes" : ["scope3", "scope2"]
"servers": ["https://server2/.well-known", "https://server3/.well-known"]
}
]
}

~~~

## Action Items
- Atul to write drafts for both issues discussed today