WG Meeting: 2024-04-02

# WG Meeting: 2024-04-02 https://hackmd.io/@oidf-wg-sse/wg-meeting-20240402/edit ## Agenda - Existing action items (5 min) - Continued discussion (0 min) - Open PRs (10 min) - Recent issues (15 min) - Other topics (30 min) ## Attendees Please add yourself here or enter your name and organization in the chat. - Shayne Miel (Cisco) - Sean O'Dell (Disney) - Mike Kiser (SailPoint) - Atul Tulshibagwale (SGNL) - Stan Bounev (VeriClouds) - Andrii Deinega - Dean Saxe (AWS) - Yair Sarig (VMWare) - Tim Cappalli (Okta) - Nancy Cam winget (Cisco) - Jeff Broberg (Self) - Jen Schreiber (Workday) - Apoorva Deshpande (Okta) ## Exiting action items - Stan/Sean: Add use cases to repo - Sean O. This is a todo for me: Getting to it on Thursday / Friday and will create the .md for it to then be expanded upon, post feedback for the approach - (Sean) Embedding the use cases in the spec helps a lot, so I'm going to use that strategy - (Mike) Is it being prescriptive? That's a danger - (Sean) It's being descriptive. E.g. How you could use aliases if you had certain constraints - (Sean) The use-cases document is a separate document from the actual spec - (Stan) Separate document makes sense - (Atul) I think we have agreement that putting examples in the "use cases spec" is a good way to go forward - Steve: Follow up with Gail on slack about OpenID meetup before IIW - - Shayne: PR for encrypting SETs based on today's conversation, dynamic client registration [DONE] ## Continued discussion (0 min) ## Open PRs (10 min) ### [142: Clarify verify event response code](https://github.com/openid/sharedsignals/pull/142) - One approval. Waiting on a second. - (Atul) What is the special case for the verify event to specify the push response here? - (Apoorva) During the interop we were seeing variations in how a receiver responds - (Apoorva) I will think about the special requirements here - ### [148: Optional receiver_key to enable encryption of SETs](https://github.com/openid/sharedsignals/pull/148) - (Atul) I am concerned about key lifecycle of keys - (Sean) We can refer to the SET spec for how to encrypt the SET - (Shayne) We already refer to that in the PR - (Shayne) For lifecycle: If you set the receiver key in the stream creation, you can change the key later when you create a new key. There may be a way to update the key in dynamic client registration - (Apoorva) The signing key is specified in the Transmitter Metadata, whereas for encryption, we're doing it at the stream level - (Apoorva) The receiver could publish a jwks URL, which the Transmitter can consume - (Jen) That is just DCR. You can easily update the key with DCR - (Sean) In the implementer's role, the odds that your receiver is doing this correctly is < 50%. Most receivers are going to authorize using a bearer token - (Sean) Not all receviers can support having a JWKS endpoint...which led to Jen's statment below - (Jen) Are you saying most implementers won't be able to generate a keypair? In that case encryption won't be possible. I recommend we add that as a requirement. "If the receiver cannot provide a receiver key, then encryption is not possible." - (Stan) We don't need to prescribe what kind of encryption needs to happen - (Apoorva) Every subject is PII - (Sean) Generally yes, but if I choose opaque identifiers then it's not PII - (Atul) Is it a requirement? - (Shayne) It is a "SHOULD" - (Sean) If we're sending SETs between companies, then we SHOULD encrypt, but if it is internal, it may not be required - (Dean) TLS is sufficient for endpoint-to-endpoint encryption. But in the SCIM working group, there are cases where the TLS endpoint is not within your control, in that case you would need the JWT encryption. So the language should be interpreted as "TLS is sufficient if it is end-to-end, but not sufficient if not end-to-end" - (Mike) SCIM events draft section for ref: https://www.ietf.org/archive/id/draft-ietf-scim-events-04.html#name-security-considerations - (Sean) Most organizations won't have end-to-end TLS, so encryption may be required - (Dean) We shouldn't require DCR, we can just host the jwks.json - (Apoorva) We could define a "Receiver Metadata" and have this as a member of that metadata - (Shayne) It's simpler to implement a Receiver than a Transmitter - (Sean) I don't agree - (Shayne) I wonder if there is value in keeping it as a part of the stream, so that the Receiver doesn't have to publish a metadata - (Sean) I agree - (Atul) I prefer this to be within the stream instead of a metadata doc, but I'm OK with doing that - (Yair) Who has the responsibility to rotate the key? Is it the receiver? - (Shayne) The Receiver, because it owns the key - (Shayne) The way the PR is written, you could use DCR or you could specify the key in creating the stream - (Yair) The benefit of being in the stream, then it becomes the responsibility of the receiver to provide the key or not to get the encryption feature - (Yair) We don't like the DCR spec for various reasons, so this is a good option - (Tim) We need to get V1 out, so this should be a "V2" thing. It's been too long. - (Sean, Atul) Agree to Tim's comment - (Dean) The risk is that you end up with proprietary implementations and get incompatible implementations - (Tim) It's the same concern with the variations of implementations in the spec (e.g. subject identifiers) - (Dean) The risk may come down to compliance, especially in terms of PII - (Tim) We can argue that there already are mechanisms defined to do encryption - (Jen) It feels like implementation detail. The parties involved can decide what works for them - (Sean) Easiest path is to put the link to the jwks.json in the stream, and then use JWE - (Atul) In my opinion, encryption is an advanced use case, and can be addressed post-final - (Shayne) Can we add something to the Security Considerations section? - (Atul) Non-normative additions are fine ### [134: Include OAuth specifics in the interop spec](https://github.com/openid/sharedsignals/pull/134) - Waiting on changes from feedback - (Stan) I want to ask a question about OAuth requirements - (Stan) To what extent would requiring OAuth impact the adoption of the spec? - (Atul) I think having these OAuth details helps interoperability and is a positive development - (Sean) If you make it declarative like that, does it make the implementations too rigid (by limiting the scopes that are allowed) - (Atul) We should rely on [OPRM](https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/) for determining scopes - (Apoorva) That's fair - (Sean) Please update the notes with the link to OPRM - (Atul) done - (Apoorva) Why did we not agree to using OPRM earlier? - (Atul) Because the OPRM spec had a limitation (which has been removed) of addressing multiple resources within the same Resource Server - ### [120: Issue 116 - Added support for receiver streams](https://github.com/openid/sharedsignals/pull/120) - Wait for Phil Hunt for discussion ## Recent Issues (15 min) ### [143: Push based- Incorporate Server-Sent Events (SSE)](https://github.com/openid/sharedsignals/issues/143) ## Other topics (30 min) Sean O. - Introduction `txn` claim into the SET to support future events Sean O. SCIM Events + SSF ### Clarify meaning of adding subjects ## New Action Items