[Openid-specs-risc] call notes
Atul Tulshibagwale
atul at sgnl.ai
Wed Jun 21 00:40:22 UTC 2023
Hi Phillip,
A "subject" claim, as specified here:
https://github.com/openid/sharedsignals/blob/ae0cf793477bff3953001b1f4ef04da78b9325e1/openid-sharedsignals-framework-1_0.txt#L2656
On Tue, Jun 20, 2023 at 5:34 PM Phillip Hunt <phil.hunt at independentid.com>
wrote:
> Atul,
>
> Are you referring to the sub_id claim?
>
> Phil
>
> On Jun 20, 2023, at 4:54 PM, Atul Tulshibagwale <atul at sgnl.ai> wrote:
>
>
> 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/9a4bdba7/attachment-0001.html>
More information about the Openid-specs-risc
mailing list