[Openid-specs-risc] call notes
Atul Tulshibagwale
atul at sgnl.ai
Tue Jun 20 23:54:28 UTC 2023
Hi Phil,
If all SSF events were required to have a top-level "subject" field with
the subject identifier in it, would the issue be still as bad? In my new
PR, The spec (11.1.2) requires all events to have a subject field. There
were a few exceptions, but we have now addressed them in this PR:
https://github.com/openid/sharedsignals/pull/70
Atul
On Tue, Jun 20, 2023 at 4:46 PM Phillip Hunt <phil.hunt at independentid.com>
wrote:
> Apologies for not making the call it seems tuesdays are often conflicting
>
> I was a little confused about stream id vs subject id in today’s
> discussion.
>
> In my issue I would like to see the subject of the event identified in the
> top-level of an event so that a router does not have to parse the event
> body itself if it is doing things like filtering out subjects that are not
> part of an individual stream (to facilitate add/remove subject in stream
> management). For example the router receivers an event from a source and
> then re-publishes to one or more streams.
>
> AFAIK there is no need to put stream id in an event itself.
>
> Phil
>
> On Jun 20, 2023, at 11:07 AM, Atul Tulshibagwale via Openid-specs-risc <
> openid-specs-risc at lists.openid.net> wrote:
>
>
> Hi all,
> Thanks to those who attended the call today. The notes are pasted below
> and stored here <https://hackmd.io/@oidf-wg-sse/wg-meeting-20230620>.
>
> Atul
>
> --
>
> <https://sgnl.ai>
>
> Atul Tulshibagwale
>
> CTO
>
> <https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
> <atul at sgnl.ai>
>
> WG Meeting: 2022-06-20 <https://hackmd.io/Pjy4fZvuTLGxfJYpez6YgA#Agenda>
> Agenda
>
> - Which Issues must be addressed before requesting another
> implementer’s draft
> - Issue #53 <https://github.com/openid/sharedsignals/issues/53> -
> ComplexSubject should have a format field
> - Issue #52 <https://github.com/openid/sharedsignals/issues/52> -
> Should subject identifier be pulled out of the event definitions?
> - Issue #60 <https://github.com/openid/sharedsignals/issues/60> - Are
> subjects required in SSF events?
>
> <https://hackmd.io/Pjy4fZvuTLGxfJYpez6YgA#Attendees>Attendees
>
> - Atul Tulshibagwale (SGNL)
> - Topher ()
> - Shayne Miel (Cisco)
> - Mike Kiser (SailPoint)
> - Tim Cappalli (Microsoft)
> - Apoorva Deshpande (Okta)
> - Eric Karlinsky (Okta)
>
> <https://hackmd.io/Pjy4fZvuTLGxfJYpez6YgA#Notes>Notes
> <https://hackmd.io/Pjy4fZvuTLGxfJYpez6YgA#Which-Issues>Which Issues
>
> - [Atul] Let’s try to submit a new implementer’s draft for review in
> the next 10 days. (Before June 30th)
>
>
> <https://hackmd.io/Pjy4fZvuTLGxfJYpez6YgA#Issue-53---ComplexSubject-should-have-a-format-field>
> Issue #53 <https://github.com/openid/sharedsignals/issues/53> -
> ComplexSubject should have a format field
>
> - Steve Venema’s suggestion on email: Add value for the field “format”
> as “complex”
> - [Tim] Would this lead to an issue in nesting, where a nested value
> could also be complex
> - [Shayne] Suggesting something like this:
>
> subject: {
> "format" : "complex",
> "user" : {
>
> },
> "tenant": {
>
> },
> "device": {
>
> }}
>
>
> - [Shayne] So we just add a field named “format”:“complex” and keep
> the rest of the spec the same
> - [Atul] The Array option we discussed the last time allows for
> duplicate entries
> - [Shayne] Prefer either this new one we discussed today or the first
> one in last week’s notes
> <https://hackmd.io/@oidf-wg-sse/wg-meeting-20230613> (a field named
> format, and a field named value)
> - [Shayne] Any component could benefit from using the “format” field
> to make a decision on subject processing
> - [Tim] We could get the same effect by adding a field named “type”,
> which could be “simple” or “complex”, and then the subject value
> - [Tim] We could go with Steve’s proposal but we may now have to add
> processing logic in the spec (not just because of Steve’s proposal, but
> because of the complexity in general)
>
>
> <https://hackmd.io/Pjy4fZvuTLGxfJYpez6YgA#Issue-52---Should-subject-identifier-be-pulled-out-of-the-event-definitions>
> Issue #52 <https://github.com/openid/sharedsignals/issues/52> - Should
> subject identifier be pulled out of the event definitions?
>
> - [Shayne] This was Phil’s request from a couple of calls ago
> - Why did RISC originally move the subject identifiers to a different
> claim than the top-level “sub” claim in JWTs?
> - Mike Kiser to ask Phil for clarification
> - [Tim] We can add a stream ID in the event for clarity / routing
> purposes. It could help in auditing
> - [Apoorva] A Transmitter implementation may become complex if we add
> a stream ID in the event, because the Transmitter cannot reuse the event
> across different streams
> - [Tim] It’s optional so should it be a problem
> - [Atul] Will it affect interoperability
> - [Tim] JSON objects are intended to have optional values, without
> affecting interoperability
> - [Atul] Won’t the transmitter have to generate a new event for every
> receiver anyway (event-id, aud, etc.)
> - [Apoorva] ‘aud’ is a list, so you could define a list of all
> receivers, and reuse the same event
>
>
> <https://hackmd.io/Pjy4fZvuTLGxfJYpez6YgA#Issue-60---Are-subjects-required-in-SSF-events>
> Issue #60 <https://github.com/openid/sharedsignals/issues/60> - Are
> subjects required in SSF events?
>
> - [Shayne] We can add a qualification that the subject value is
> required for all events other than “stream updated” and “verification”
> events.
> - [Eric] It feels a little contorted to do it this way. Can we instead
> make the “stream updated” event not SSF conformant?
> - [Atul] We can add a stream ID subject in the “stream updated” event.
> - [Shayne, Eric] We should have thst subject to be opaque, and specify
> how it should be defined
> - [Eric, Shayne, Atul] like the “Add stream id as subject” option more
> - [Shayne] what about subscription to that subject?
> - [Atul] Should be automatic
> - [Shayne] The receiver should be able to remove that subject if needed
> - [Atul] That could be problematic, we should not allow removal of
> that subject
>
> <https://hackmd.io/Pjy4fZvuTLGxfJYpez6YgA#Action-Items>Action Items
>
> - Atul to add PR to add subject to “stream updated” and “verification”
> events
>
> <https://hackmd.io/Pjy4fZvuTLGxfJYpez6YgA#>
> Select a repo
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-risc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230620/fc669612/attachment-0001.html>
More information about the Openid-specs-risc
mailing list