[Openid-specs-risc] call notes
Atul Tulshibagwale
atul at sgnl.ai
Wed Jun 21 19:37:17 UTC 2023
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>
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>
> 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:
> [image: ietf-logo-card.png]
>
> 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/>
> <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> 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>
> 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/20230621/d527eb8e/attachment-0001.html>
More information about the Openid-specs-risc
mailing list