[Openid-specs-risc] Call notes
Atul Tulshibagwale
atul at sgnl.ai
Tue Aug 22 18:09:03 UTC 2023
Hi all,
Here are the notes from today's call. They are also stored here
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20230822>.
--
<https://sgnl.ai>
Atul Tulshibagwale
CTO
<https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
<atul at sgnl.ai>
<https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#WG-Meeting-2023-08-22>WG
Meeting: 2023-08-22 <https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#Agenda>
Agenda
- supported_scopes / OAuth server discovery discussion
- (smiel) Why do we have a format field in the Stream Configuration? PR
87 discussion
<https://github.com/openid/sharedsignals/pull/87#discussion_r1276951345>
<https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#Attendees>Attendees
- Atul Tulshibagwale (SGNL)
- Shayne Miel (Cisco)
- Mike Kiser (SailPoint)
- Phil Hunt (Independent ID)
- Eric Karlinsky (Okta)
- Steve Venema (ForgeRock)
- Victor Lu (Guest /)
- Yair Sarig (VMWare)
<https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#Notes>Notes
<https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#Supported-Scopes-issue>Supported
Scopes issue
- Adding “supported_scopes” causes SSF to require OAuth
- This is not considered to be reasonable for SSF
- IdPs may defined different authentication / authorization mechanisms
for SSF
- Adding any authorization specific information in SSF, it may not be
scalable for other mechanisms
- OAuth discovery can be used instead for finding scopes and
authorization servers
- Server can respond with the “WWW-Authenticate” response to
unauthenticated requests
- (Phil) Some implementations require tokens for authorization of Poll
or Push endpoints. Those implementations already require OAuth. If an admin
updates one or more streams, does the admin require different tokens?
- (Phil) Does the draft specify anything about stream with the bearer
token?
- (Shayne) With the updated draft (multiple streams), the endpoint is in
the URL and not related to the token.
- (Phil) In 8935/8936 (Poll/Push) drafts, there is no information in the
token
- You could specify the endpoint per stream
- (Phil) that would be required if we did that, do we need to add
anything in the spec
- (Phil) We’re practically in an OAuth world, so it may not be a bad
idea to have some simplification in the spec
- (Apoorva) This is not the only mechanism, there will be others, so we
should have decoupling
- (Shayne) Should we remove all authorization related information from
the SSF spec?
- (Phil) Some implementations use a bearer token incorrectly (without
the “Bearer” prefix in the header)
- (Yair) I recommend we decouple the authorization from the SSF spec
- (Steve) Do we need to …
- (Apoorva) My PR proposes that the Transmitter Configuration Metadata
can specify the authorization schemes
- (Yair) If someone has subscribed to a service, they should know how to
authorize their requests
- (Phil) Some of this work has been done in the SCIM working group
- (Phil) We should follow a model similar to SCIM in SSF, unless we want
to simplify the spec by requiring one pattern, but that might be a
tradeoff. Systems that receive events may be highly varied (including IoT),
so flexibility is good
- (Phil, Apoorva) We should perhaps soften the “Should” in Section 8 to
“May”. Apoorva’s PR removes this section.
- (Phil) We should have some discussion on authorization in the Security
Considerations section. Event delivery, administration, configuration
updates, status, etc.
- (Yair) We should mention the desired security properties of endpoints
- (Apoorva) Why should the spec bother with this?
- (Phil) Hypothetical example: client can auth to say, Google, using 3
ways, mTLS, signed event or bearer token
- (Apoorva) WG made the decision to not have signed SETs, this also ties
back to the security. “jwks_uri” was REQUIRED, and now it says OPTIONAL
- (Phil) That may be a mistake, because SCIM requires it. Events are
stored for historical use, and knowing that those events are legitimate.
- (Steve) From my perspective, interoperability is important, and this
is fundamental to it. Should we have different profiles? E.g. a bearer
token profile?
- (Steve) We won’t have to have these profiles immediately, but we can
do this as a part of the interoperability work ahead.
<https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#format-PR>format PR
- (Shayne) Do we want the format field in the stream configuration?
- (Apoorva) Adding the format in the stream configuration breaks the
flexibility that a Transmitter can provide different event types with
different subject formats
- (Phil) If you use the IETF sub_id format in SSF, then this is simple.
Multiple events can be expressed differently. Transmitter and Receiver need
to negotiate how specific events will be formatted
- (Phil) At scale, there is a challenge if each Receiver desires a
different format for the subject.
- (Shayne) When a Receiver creates a stream, they specify the
event_types and the format for the stream as a whole
- (Shayne) sub_id is abstracted away from the event type now, it is a
top-level claim now in the SET
- (Phil) Operationally, we should be able to create a stream with
different event types, for some class of events you may want certain sub_id
formats. It might be too complex
- (Apoorva) From an implementation point of view, one event could have
two different sub formats. Does the Transmitter skip events that doesn’t
match the format?
- (Phil) If the Receiver and Transmitter don’t have agreement, the
events may get ignored anyway.
- (Atul) Should we skip having the “format” field in the stream
configuration right now?
- (Phil) Or we could go with a fallback model
- (Shayne) Why would it be hard for the Receiver to not handle different
event types. Why does the receiver need to know in advance
- (Steve) Implementing all formats may not be that hard
- (Phil) They may not have the data to handle this
- (Yair) Receiver may have information about the events, but the same
user may be identified in multiple ways, the Transmitter may have multiple
ways of specifying the same event. How would the Transmitter know
- (Phil) The same subject even in the same format may be identified
differently. The Transmitter and Receiver must have agreement in advance on
how to identify the same user
- (Shayne) Having the format field doesn’t really solve the agreement
problem because of what Phil said right now
- (Phil) A common understanding of the subject is a requirement
- (Atul) Is this is a good summary: “While it’s desirable to specify the
format, there doesn’t seem to be a simple way to do this, so we should skip
the format field from the stream configuration right now”?
- (Shayne) If we keep the format field, then we must specify what the
Transmitter needs to send an event in an unsupported format
- (Phil) When the stream gets setup, the Receiver specifies the format,
but the Transmitter specifies the format it supports. The Receiver can
agree to the formats then they continue, else the Receiver ends the stream
- (Atul) There could be a race condition that multiple events are sent
before the Receiver ends the stream
- (Phil) We could make this a part of the discovery
- (Steve) So should the next implementer’s draft should remove the
format field from the configuration?
- (Phil) So it would be an out-of-band issue. This could become an
interop problem
- (Shayne) Any implmentation should support all formats in the SSF spec
- (Steve) Can we add non-normative text that this is a current issue
with the spec.
<https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#Action-Items>Action Items
- Phil to review spec and find out if the authorization is decoupled
from OAuth - issue preferred, but email is OK
- Discuss SET signing issue in next call, anyone with background
information please email the group
- Shayne to update PR to remove the “format” field from the stream
configuration.
- WG Meeting: 2023-08-22
<https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#WG-Meeting-2023-08-22>
- Agenda <https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#Agenda>
- Attendees <https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#Attendees>
- Notes <https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#Notes>
- Action Items
<https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#Action-Items>
Expand all <https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#>Back to top
<https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#>Go to bottom
<https://hackmd.io/5ViZLYjBQTKmn3zw-gJM6Q?view#>
Select a repo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230822/178635d7/attachment-0001.html>
More information about the Openid-specs-risc
mailing list