[Openid-specs-risc] Call notes
Atul Tulshibagwale
atul at sgnl.ai
Wed Aug 30 00:51:27 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-20230829>:
Atul
--
<https://sgnl.ai>
Atul Tulshibagwale
CTO
<https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
<atul at sgnl.ai>
WG Meeting: 2023-08-29
<https://hackmd.io/nW6HWJ4WQfaX2ZAnm758Uw?view#Agenda>Agenda
- Transmitter’s ability to update stream content
<https://github.com/openid/sharedsignals/issues/103>
- Empty events_requested field in Create Stream
<https://github.com/openid/sharedsignals/pull/100>
- Decoupling SSF metadata from OAuth
<https://github.com/openid/sharedsignals/pull/101>
- Conclude on format PR <https://github.com/openid/sharedsignals/pull/87>
<https://hackmd.io/nW6HWJ4WQfaX2ZAnm758Uw?view#Attendees>Attendees
- Atul Tulshibagwale (SGNL)
- Phillip Hunt (Independent ID)
- Steve Venema (Forgerock)
- Apoorva Deshpande (Okta)
- Yair Sarig (VMWare)
- Edumund Jay ()
- Tim Cappalli (Microsoft)
<https://hackmd.io/nW6HWJ4WQfaX2ZAnm758Uw?view#Notes>Notes
<https://hackmd.io/nW6HWJ4WQfaX2ZAnm758Uw?view#Transmitter%E2%80%99s-ability-to-update-stream-content>Transmitter’s
ability to update stream content
<https://github.com/openid/sharedsignals/issues/103>
- (Apoorva) I want to make sure that Transmitters have the ability to
change the subjects included in the stream
- (Atul) Should the Transmitter have to tell the Receiver that it honors
an Add Subject
- (Phil) That could lead to harvesting information from the Transmitter
- (Yair) If I create a new stream and don’t make any add subject calls,
does that mean all subjects are included are no subjects are included?
- (Phil) The initial idea was that as a part of an initial authorization
request, such add subject calls are required. In other cases, e.g. SCIM,
all subjects are included by default
- (Atul) I agree we don’t need to put strong normative language in the
semantics of the Create Stream
- (Phil) It could be a Transmitter discretion whether or not they should
indicate whether an AddSubject succeeded or not
- (Yair) There may be additional fields that indicate to the Transmitter
whether all subjects should be included or not
- (Phil) We could add a filter at the time of stream creation
- (Steve) There’s a concrete use case for this: Our infosec would like
to know about any “forgerock.com” identity for a subset of events that
Google could notify us for. In our case, “forgerock.com” is not a
separate tenant of Google
- (Phil) Would a Receiver want to know the total universe of subjects in
the stream?
- (Apoorva / Steve) That sounds a bit like SCIM
- (Steve) The filter seems to have value
- (Phil) There are possibly two use cases:
- User centric: User needs to consent to share events. The spec is
well designed for this.
- Enterprise use case: Consent belongs to the enterprise, so every
account using a specific service must be included in the stream
- (Phil) Does this lead to an interop issue
- (Phil) In a typical SCIM use case all subjects are included by
default. This is more of an admin issue than an interop issue
- (Apoorva) How would a transmitter limit the audience of a stream to
only a certain number of users
- (Atul) Two issues here:
- What is the semantics when the stream is created
- How does the Transmitter add / remove subjects
- (Yair) Filtering may be useful in many cases
- (Phil) What if we just spec-ed that the Transmitter is always
authoritative over what subjects it sends events about. The Transmitter may
add or remove subjects as it desires.
- (Phil) We could leave the spec unchanged, because it can be configured
administratively
- (Phil) We could leverage the SCIM filter language that is based on
path. But what are you filtering against.
- (Phil) Issue with adding a filter e.g. email ends with @okta.com, what
is the Transmitter comparing that against?
- (Steve) Events won’t be sent if they don’t match the filter
specification
- (Phil) We don’t want to force the Transmitter to look up a database
before sending an event
- (Yair) The device use cases, the id is only a device ID, and the
Transmitter may not have this information
- (Atul) Should we list this as a “known issue” in the spec?
- (Phil) agree, but we should make sure that any normative language
about subject content in the stream should be avoided. This will enable us
to craft a more specific solution later that doesn’t break backward
compatibility
- (Phil) Even SCIM is trying to define how to define the scope of each
domain
<https://hackmd.io/nW6HWJ4WQfaX2ZAnm758Uw?view#Decoupling-SSF-metadata-from-OAuth>Decoupling
SSF metadata from OAuth <https://github.com/openid/sharedsignals/pull/101>
- (Atul) Value of the “scheme” field can be the URN
-
<https://hackmd.io/nW6HWJ4WQfaX2ZAnm758Uw?view#Empty-events_requested-field-in-Create--Update-Stream>
Empty events_requested field in Create / Update Stream
<https://github.com/openid/sharedsignals/pull/100>
- (Apoorva) What would be the use of creating a stream with no
“events_requested”
- (Phil) There’s a way around this: There are three params:
- events_requested
- events_supported
- events_delivered
- (Phil) If events_requested is missing, events_delivered should remain
unaltered?
- (Phil) If events_requested is not asserted, then it means that the
Receiver is not specifying which events
- (Phil) You could be requesting events A, B, and C. But you’ve only
paid for A and B, so the Transmitter only includes A and B in the stream
- (Apoorva) In the current spec, the events_delivered is a pure
intersection of event_requested and events_supported
- (Phil) We then need to update this “intersection” language
- (Phil) supported describes technical capabilities, delivered means
what you actually get
- (Atul) supported could also mean just what is desired
<https://hackmd.io/nW6HWJ4WQfaX2ZAnm758Uw?view#Action-Items>Action Items
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230829/74bff50c/attachment-0001.html>
More information about the Openid-specs-risc
mailing list