# WG Meeting: 2022-
## Agenda
- Pull requests
- Standardized scopes
- Subject Identifiers

## Attendees
- Atul Tulshibagwale (SGNL)
- Shayne Miel (Cisco)
- Eric Karlinsky (Okta)
- Topher Marie (Strata)
- Steve Venema (ForgeRock)
- Apoorva Deshpande (Okta)
- Phil Hunt (Independent ID)

### Guests
- Muneera (Apple)

## Notes
### Pull Requests
- Most pull requests are merged. A few waiting on a pending review
- Building HTML. Look at: <put url here></put>

### Standardized Scopes
- [Eric] How does a Receiver know which scopes to request in order to setup a stream
- [Atul] Can extend that to other functionalities, e.g. Poll a Stream
- [Eric] Can we have an attribute in the well-known endpoint, which is an array of scopes that are supported. It could be two separate attributes. This could solve it.
- How does a Receiver know which of the scopes are absolutely needed versus not needed.
- There should be some indication of which scopes can do what
- [Atul] I had a proposal:

~~~ json
{
"issuer":
"https://tr.example.com",
"jwks_uri":
"https://tr.example.com/jwks.json",
"delivery_methods_supported": [
{ "method": "urn:ietf:rfc:8935" },
{
"method": "urn:ietf:rfc:8936",
"scopes_supported": ["poll_stream", "read"]
}
],
"configuration_endpoint": {
"url": "https://tr.example.com/ssf/mgmt/stream",
"scopes_supported": ["create_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" ]
}
~~~
- [Eric] For any of this, we need authentication
- [Eric] We should require the metadata to have scopes if an endpoint requires authentication
- [Phil] I'd expect there to be an OAuth server to issue the token with the scopes. And what is the nature of the client? Is it another SSF server? Is it a command line tool?
- [Phil] If you're building a command line tool, you need to specify both endpoints, but the spec defines only one endpoint
- [Phil] The spec assumes it is always one server talking to another token
- [Atul] Just putting scopes doesn't define where the AuthZ server is
- [Shayne] Access token doesn't contain the stream ID
- [Steve] Interop will be a pain point if we don't have standardized scopes
- [Steve, Atul] We could recommend a set of scopes and still allow other scopes to be used
- [Eric] What is the namespace these scopes are in? Are they globally unique? How do we avoid conflicts with existing scopes?
- [Steve] Can we define a SSF namespace?
- [Shayne] Do they need to be globally unique? The OpenID Connect scopes seem very simple like "profile" or "email"
- [Phil] You don't need to register with IANA, you can just use a URN syntax like `urn:openid:ssf:create_stream` or something like that
- Everyone on the call agrees that having a few standard scopes that are recommended, but allowing Transmitters to use different scopes will be a good addition to the spec

### Subject Identifiers
- [Atul] Should subjects be at the top level, or should they be inside events. Also, should we use "sub_id" as the SecEvents Subject Identifiers spec is now standardizing that.
- [Phil] From a common processing / routing point of view, how can a router or processor avoid having to parse individual events. It should just be able to parse top-level items such as "aud" or "exp"
- [Phil] Streams may need to filter by subjects, if it is at the top-level, it will be better
- [Shayne] Can we do both? Always put it at the top-level, but include it within the event when the event demands it
- [Atul] Does putting "subject" as a required field in every "events" claim solve?
- [Phil] This could be problematic if events are encrypted. The subject being available at the top-level can help route events even if the contents are encrypted
- [Phil] The point is to use a registered claim.
- [Apporva] If routing is the concern, wouldn't it suffice to put the stream id in the JWT?
- [Shayne] The stream ID is specific to the Tx - Rx communication, so shouldn't be in the JWT
- [Phil] My use case: Each SCIM server in a cluster is using a common router to push events. You may have multiple hops involved before the SCIM Receiver receives the event. You will need to re-sign the event at each hop if the stream ID is in the JWT.
- [Atul] Since the stream ID information is at the URL level, even before getting to the JWT, so it's not a concern for routing
- [Phil] A single trigger may cause a SCIM and a RISC event (e.g. password changed), and if the formats are different, the routing logic for each type of event will need different processing
- [Shayne] Existing events that have encrypted payloads don't use SSF right now, extracting the `sub_id` to the top-level may enable those events to use SSF
- [Steve] Struggling with a single subject. How would you decide which is the more important subject in a hypothetical "transfer" event.
- [Phil] We need the concept of a primary subject, otherwise how would you do "add subject" and "remove subject"
- [Steve] We have "complex" in SSF, but the SubIds draft talks about "aliases", can we reconcile those?
- [Phil] I only realized this because we cannot deploy SET PUSH and POLL on a point-to-point basis. We have to have recovery points, and routing becomes important.
- [Steve] We have the PUSH and POLL RFCs, does it make sense to have a different RFC for these complex store and forward cases?
- [Phil] SSF defines registration (which is different for push vs poll)
- [Apoorva] Circling back to the encryption requirement. If we encrypt the event, and have a sub_id that is outside, won't we be leaking PII? We would need to encrypt the subject in order to get this. (+1 from Shayne and Phil)
- [Atul] We may want to keep the spec the same to avoid conflicting with existing implementations
- [Phil] If SCIM and CAEP/RISC events differ a lot, then the processing infrastructure gets complex. Non-standard placement of subject will kill interop
- [Steve] If you add a top-level claim then doesn't the spec say you can ignore that claim.
- [Atul] Should we discuss the top-level sub_id with replication in events?

## Action Items
- Atul to create an issue to describe the scopes requirement
- Shayne to double check if he has proposed the top-level sub_id in the GitHub issue.
- Phil to investigate whether unknown claims are required to be understood