[Openid-specs-risc] Meeting notes for 2024-04-02

Tue Apr 2 20:00:23 UTC 2024

Hi all,
Here are the notes from today's meeting. They are also stored here
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20240402>.

Thanks,
Atul
--

<https://sgnl.ai/>

Atul Tulshibagwale

CTO

<https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
<atul at sgnl.ai>

---

WG Meeting: 2024-04-02

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
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
(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
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 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
Wait for Phil Hunt for discussion
Recent Issues (15 min)
143: Push based- Incorporate Server-Sent Events (SSE)
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20240402/43f953d0/attachment.html>