[Openid-specs-risc] call notes

[Atul Tulshibagwale]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230620/301ce460/attachment-0001.html>