[Openid-specs-risc] call notes

Wed Jun 21 20:11:00 UTC 2023

I added an example.  It should be clearer.

Phillip Hunt
phil.hunt at independentid.com

> On Jun 21, 2023, at 12:37 PM, Atul Tulshibagwale <atul at sgnl.ai> wrote:
> 
> Hi Phil,
> There's a related issue here: https://github.com/openid/sharedsignals/issues/52. Could you please add your comments on this issue so that we can determine what course of action to take?
> 
> Thanks,
> Atul
> 
> On Tue, Jun 20, 2023 at 5:56 PM Phillip Hunt <phil.hunt at independentid.com <mailto:phil.hunt at independentid.com>> wrote:
>> Yes. That is so close to sub_id it makes sense to use it. 
>> 
>> Phil
>> 
>>> On Jun 20, 2023, at 5:55 PM, Phillip Hunt <phil.hunt at independentid.com <mailto:phil.hunt at independentid.com>> wrote:
>>> 
>>> The sub_id is per the new subject identifier draft at IETF. 
>>> 
>>> It would be a registered top-level claim. In contrast payload claims do not need registration. 
>>> 
>>> The sub_id has a format sub-claim which could be “caep” and then caep defines what other claims go in the same json structure. 
>>> 
>>> The scim events draft does this. See:
>>> 
>>> SCIM Profile for Security Event Tokens
>>> datatracker.ietf.org
>>>  <https://datatracker.ietf.org/doc/draft-ietf-scim-events/>SCIM Profile for Security Event Tokens <https://datatracker.ietf.org/doc/draft-ietf-scim-events/>
>>> datatracker.ietf.org <https://datatracker.ietf.org/doc/draft-ietf-scim-events/>
>>> The scim format defines what “id” and other claims/attributes mean. 
>>> 
>>> Btw. As a todo I still have to register the new scim format in the draft.
>>> 
>>> Phil
>>> 
>>>> On Jun 20, 2023, at 5:40 PM, Atul Tulshibagwale <atul at sgnl.ai <mailto:atul at sgnl.ai>> wrote:
>>>> 
>>>> 
>>>> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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>  <mailto: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 <mailto: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/20230621/399ce06e/attachment-0001.html>