Subject: [Id-event] Options regarding SPAGs

From: Atul Tulshibagwale <[email-masked]>
Date: Thu, 3 Dec 2020 15:03:41 -0800

Hi all,
Based on Dick's request, I'd like to summarize the situation with SPAGs
here.

*Background*:
The present Subject Identifiers draft
<https://github.com/richanna/secevent/blob/1fd045d251ff3c6be9a500c6a78d895be3c6b2bf/draft-ietf-secevent-subject-identifiers.txt>
forbids a subject identifier of a specific subject_type from having any
claims that are not described in the subject_type. This prevents
higher-level specs from proposing any additional claims to be included in
subject identifiers of subject types that are defined in the Subject
Identifier spec.

*SPAGs*:
Subject Principal Administrative Groupings or SPAGs are an addition to the
OpenID "Shared Signals and Events Profile of SETs"
<https://bitbucket.org/openid/risc/src/caep-draft-01/openid-sse-profile-2_0.txt>,
which is a revision of the "RISC Profile of SETs
<https://bitbucket.org/openid/risc/src/master/openid-risc-profile-1_0.txt>".
The present draft of the SecEvents Subject Identifiers spec is derived from
a section in this RISC Profile. The SSE Profile now refers to the SecEvents
Subject Identifiers draft.

SPAGs are required to address the following needs:

   1. Disambiguate a subject identifier if it belongs to more than one
   sub-organizations. For example, if the subject claim in an event is of the
   subject type "email", then a SPAG may be used to specify the
   sub-organization the specified email should be scoped down to. A dynamic
   organization may have the same email in multiple sub-organizations, and the
   event may apply to only one such sub organization.
   2. Provide a lighter weight mechanism to start and stop event streams
   for sub-organizations. These could be OUs or dynamic groups within an
   organization, or separate tenants in a multi-tenanted transmitter or
   receiver.

*Requirements from Subject Identifiers*:

   1. A SPAG may be specified as an additional attribute of a subject
   identifier with any subject type, in order to disambiguate and scope the
   event with that subject identifier.
   2. A SPAG may be a new subject type of its own when it is used in an
   event that specifies the starting or stopping of a stream.

*Options*:
The following options are possible to address this requirement.

   1. *Minimal Change to the present Subject Identifiers draft*: Remove the
   words "or not described" on line 247
   <https://github.com/richanna/secevent/blob/1fd045d251ff3c6be9a500c6a78d895be3c6b2bf/draft-ietf-secevent-subject-identifiers.txt#L247>.
   This way a higher-level spec that needs to add additional attributes to all
   subject identifiers used in that spec can add them and specify the
   additional attributes' optional or required nature. In this option, SPAGs
   will be defined in the SSE profile spec.
   2. *Include SPAGs in the Subject Identifiers spec*: Include language for
   SPAGs proposed earlier in this list, so that:
      1. Subject Principals and SPAGs are defined in the Subject
      Identifiers spec
      2. An additional attribute named "spag_id" is added as an optional
      attribute of any subject_type.
      3. An additional subject_type "spag" is defined (this is used
      primarily for "control plane" events.)
   3. *Do both 1. and 2*: With this, we will address the issue that
   higher-level specs cannot insert additional attributes in predefined
   subject types, and define SPAGs within the Subject Identifiers spec.

Thanks,
Atul

---

From: Dick Hardt <[email-masked]>
Date: Thu, 3 Dec 2020 17:41:54 -0800

I think there is also a fourth option:

4. a SPAG identifier can be placed in a separate top level object or top
level property

Atul: in the other thread, you mentioned that there were other additions
that the OpenID Shared Signals and Events WG is interested in. Would you
enumerate them as well so that we can address all potential issues?

ᐧ

On Thu, Dec 3, 2020 at 3:04 PM Atul Tulshibagwale <atultulshi=
[email-masked]> wrote:

>    1. *Minimal Change to the present Subject Identifiers draft*: Remove
>    the words "or not described" on line 247
>    2. *Include SPAGs in the Subject Identifiers spec*: Include language
>    for SPAGs proposed earlier in this list, so that:
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>

---

From: Atul Tulshibagwale <[email-masked]>
Date: Fri, 4 Dec 2020 16:40:50 -0800

Hi Dick,
#4 may not always be an option if the event has more than one subject claim
(e.g. for an event like "device transfer").

Regarding other additions:
*Subject Categories*:
Earlier, I had proposed that a subject identifier of any subject_type have
an optional common claim named "subject_category", which could identify the
type of subject principal the subject identifier refers to. However, since
the future of this request in the Subject Identifiers spec wasn't clear, we
decided to add a new "subject_type" in the SSE spec, called
"user-device-session". The SSE spec draft defines the algorithm to figure
out the category of the subject principal based on the content of this
subject identifier.

As a result of this new subject type definition in the SSE spec draft,
"subject_category" is no longer a requirement for the SSE work. However,
since the SSE spec is still being drafted, if the Subject Identifiers spec
has the ability to add a subject category claim to any subject_type, then
we can possibly change the SSE spec to make use of it.

*SAML Subject Type*:
I had proposed that a SAML subject type be introduced in the Subject
Identifiers. This will help us send and receive events relating to a
specific SAML-based federated session. I thought this would be a common
subject type of interest to the Subject Identifiers spec. However, we have
now added it as a subject type in the SSE draft spec. If the Subject
Identifiers draft were to include this, it would be very easy for us to
remove this from the SSE draft spec.

BTW a good way to look at all my proposed changes to the Subject
Identifiers draft is by reviewing my pull request here:
https://github.com/richanna/secevent/pull/1

Thanks,
Atul

On Thu, Dec 3, 2020 at 5:43 PM Dick Hardt <[email-masked]> wrote:

>> Subject Principal Administrative Groupings or SPAGs are an addition to
>> the OpenID "Shared Signals and Events Profile of SETs"

---

From: Phillip Hunt <[email-masked]>
Date: Sat, 5 Dec 2020 09:04:01 -0800

When we first started discussions around SET, one goal was to keep events simple/atomic. If multiple subjects are effected by the same event, why not issue multiple events and a “txn” value to indicate each SET is part of the same parent event/transaction?

Creating compound events to express full context creates a lot of contextual “binding” between sender and receiver. 

I am not saying multiple subjects is always wrong. But this begins to feel like a lot of parsing complexity (affecting event parsing speed) on every message rather than send a few more simple messages.  For example ksql can capture multiple events in a stream to learn that the same event for multiple subjects is related if that needs to be known. 

Phil

> On Dec 4, 2020, at 4:41 PM, Atul Tulshibagwale <atultulshi=[email-masked]> wrote:
> 
> 
> Hi Dick,
> #4 may not always be an option if the event has more than one subject claim (e.g. for an event like "device transfer"). 
> 
> Subject Categories:
> Earlier, I had proposed that a subject identifier of any subject_type have an optional common claim named "subject_category", which could identify the type of subject principal the subject identifier refers to. However, since the future of this request in the Subject Identifiers spec wasn't clear, we decided to add a new "subject_type" in the SSE spec, called "user-device-session". The SSE spec draft defines the algorithm to figure out the category of the subject principal based on the content of this subject identifier.
> 
> As a result of this new subject type definition in the SSE spec draft, "subject_category" is no longer a requirement for the SSE work. However, since the SSE spec is still being drafted, if the Subject Identifiers spec has the ability to add a subject category claim to any subject_type, then we can possibly change the SSE spec to make use of it.
> 
> SAML Subject Type:
> I had proposed that a SAML subject type be introduced in the Subject Identifiers. This will help us send and receive events relating to a specific SAML-based federated session. I thought this would be a common subject type of interest to the Subject Identifiers spec. However, we have now added it as a subject type in the SSE draft spec. If the Subject Identifiers draft were to include this, it would be very easy for us to remove this from the SSE draft spec.
> 
> BTW a good way to look at all my proposed changes to the Subject Identifiers draft is by reviewing my pull request here: https://github.com/richanna/secevent/pull/1
> 
> Thanks,
> Atul
> 
> 
>> 4. a SPAG identifier can be placed in a separate top level object or top level property
>> 
>> Atul: in the other thread, you mentioned that there were other additions that the OpenID Shared Signals and Events WG is interested in. Would you enumerate them as well so that we can address all potential issues?
>> 
>> 
>> ᐧ
>> 
>>> On Thu, Dec 3, 2020 at 3:04 PM Atul Tulshibagwale <atultulshi=[email-masked]> wrote:
>>> Hi all,
>>> Based on Dick's request, I'd like to summarize the situation with SPAGs here.
>>> 
>>> Background:
>>> The present Subject Identifiers draft forbids a subject identifier of a specific subject_type from having any claims that are not described in the subject_type. This prevents higher-level specs from proposing any additional claims to be included in subject identifiers of subject types that are defined in the Subject Identifier spec.
>>>  
>>> SPAGs:
>>> Subject Principal Administrative Groupings or SPAGs are an addition to the OpenID "Shared Signals and Events Profile of SETs", which is a revision of the "RISC Profile of SETs". The present draft of the SecEvents Subject Identifiers spec is derived from a section in this RISC Profile. The SSE Profile now refers to the SecEvents Subject Identifiers draft.
>>> 
>>> Disambiguate a subject identifier if it belongs to more than one sub-organizations. For example, if the subject claim in an event is of the subject type "email", then a SPAG may be used to specify the sub-organization the specified email should be scoped down to. A dynamic organization may have the same email in multiple sub-organizations, and the event may apply to only one such sub organization.
>>> Provide a lighter weight mechanism to start and stop event streams for sub-organizations. These could be OUs or dynamic groups within an organization, or separate tenants in a multi-tenanted transmitter or receiver.
>>> Requirements from Subject Identifiers:
>>> A SPAG may be specified as an additional attribute of a subject identifier with any subject type, in order to disambiguate and scope the event with that subject identifier.
>>> A SPAG may be a new subject type of its own when it is used in an event that specifies the starting or stopping of a stream.
>>> Options:
>>> Minimal Change to the present Subject Identifiers draft: Remove the words "or not described" on line 247. This way a higher-level spec that needs to add additional attributes to all subject identifiers used in that spec can add them and specify the additional attributes' optional or required nature. In this option, SPAGs will be defined in the SSE profile spec.
>>> Include SPAGs in the Subject Identifiers spec: Include language for SPAGs proposed earlier in this list, so that:
>>> Subject Principals and SPAGs are defined in the Subject Identifiers spec
>>> An additional attribute named "spag_id" is added as an optional attribute of any subject_type.
>>> An additional subject_type "spag" is defined (this is used primarily for "control plane" events.)
>>> Do both 1. and 2: With this, we will address the issue that higher-level specs cannot insert additional attributes in predefined subject types, and define SPAGs within the Subject Identifiers spec.
>>> Thanks,
>>> Atul
>>>

---

From: Atul Tulshibagwale <[email-masked]>
Date: Mon, 7 Dec 2020 13:21:50 -0800

Hi Phillip,
Your suggestion makes sense, but I believe this is not something we have
considered in the SSE work. (Also, to be clear, the "device-transfer" is
not an event being considered in the current draft of SSE Event Types spec
either, but just something we have hypothesized about while considering
whether SPAGs belong in the event or in the subject identifier.)

So from a Subject Identifiers spec perspective, the alternative (i.e. #4 in
Dick's email) to not include a SPAG identifier as a claim in the Subject
Identifier is valid.

However since I believe it is a property of the subject principal rather
than of the event, I'd prefer it to be a claim in the Subject Identifier.

Separately, I'd also like to understand the issue of complexity of SETs:
The limitations placed by the spec; intended but not specified by the
authors; and what issues could result from creating more complex SETs.
Right now, one SSE event is designed to be a single SET. If we have to
create multiple SETs for some events, it will be a bit of additional spec
work (and possibly downstream implementation work).

Thanks,
Atul

On Sat, Dec 5, 2020 at 9:04 AM Phillip Hunt <[email-masked]>
wrote:

> When we first started discussions around SET, one goal was to keep events
> simple/atomic. If multiple subjects are effected by the same event, why not
> issue multiple events and a “txn” value to indicate each SET is part of the
> same parent event/transaction?
>
> Creating compound events to express full context creates a lot of
> contextual “binding” between sender and receiver.
>
> I am not saying multiple subjects is always wrong. But this begins to feel
> like a lot of parsing complexity (affecting event parsing speed) on every
> message rather than send a few more simple messages.  For example ksql can
> capture multiple events in a stream to learn that the same event for
> multiple subjects is related if that needs to be known.
>
> Phil
>
> #4 may not always be an option if the event has more than one subject
> claim (e.g. for an event like "device transfer").
>
>>>    2. Provide a lighter weight mechanism to start and stop event
>>>    streams for sub-organizations. These could be OUs or dynamic groups within
>>>    an organization, or separate tenants in a multi-tenanted transmitter or
>>>    receiver.
>>>
>>>       2. An additional attribute named "spag_id" is added as an
>>>       optional attribute of any subject_type.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 7 Dec 2020 13:55:27 -0800

Atul,

RFC8417 consistently uses the term “a subject” meaning subjects are singular. 

Opening up the possibility of multi-subject events is a major change in the intent of SET. For know, I am just not comfortable with the trade-off.

Given that a SET may contain mulitiple Event URIs, how does the multiple subject identifcation apply to each event payload?  Does this create a logic bomb trying to figure out the permutations and combinations of multipe-subjects vs multiple events?

The original subject identifier spec had a lot of discussion about allowing the use of multiple subject identifier types to deal with identifier mis-matches that may occur between event publishers and subscribers. Eg. as we have seen in OIDC, RP’s don’t always track users by the same identifier as the OP.
—> If you have multiple security subjects identified, does this not further confound the OIDC identifier use case?

Phil Hunt
@independentid
[email-masked]

> On Dec 7, 2020, at 1:21 PM, Atul Tulshibagwale <[email-masked]> wrote:
> 
> Hi Phillip,
> Your suggestion makes sense, but I believe this is not something we have considered in the SSE work. (Also, to be clear, the "device-transfer" is not an event being considered in the current draft of SSE Event Types spec either, but just something we have hypothesized about while considering whether SPAGs belong in the event or in the subject identifier.)
> 
> So from a Subject Identifiers spec perspective, the alternative (i.e. #4 in Dick's email) to not include a SPAG identifier as a claim in the Subject Identifier is valid.
> 
> However since I believe it is a property of the subject principal rather than of the event, I'd prefer it to be a claim in the Subject Identifier.
> 
> Separately, I'd also like to understand the issue of complexity of SETs: The limitations placed by the spec; intended but not specified by the authors; and what issues could result from creating more complex SETs. Right now, one SSE event is designed to be a single SET. If we have to create multiple SETs for some events, it will be a bit of additional spec work (and possibly downstream implementation work).
> 
> Thanks,
> Atul
> 
> On Sat, Dec 5, 2020 at 9:04 AM Phillip Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>> On Dec 4, 2020, at 4:41 PM, Atul Tulshibagwale <atultulshi=[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> Hi Dick,
>> BTW a good way to look at all my proposed changes to the Subject Identifiers draft is by reviewing my pull request here: https://github.com/richanna/secevent/pull/1 <https://github.com/richanna/secevent/pull/1>
>> 
>> Thanks,
>> Atul
>> 
>> 
>> On Thu, Dec 3, 2020 at 5:43 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> On Thu, Dec 3, 2020 at 3:04 PM Atul Tulshibagwale <atultulshi=[email-masked] <mailto:[email-masked]>> wrote:
>> Hi all,
>> The present Subject Identifiers draft <https://github.com/richanna/secevent/blob/1fd045d251ff3c6be9a500c6a78d895be3c6b2bf/draft-ietf-secevent-subject-identifiers.txt> forbids a subject identifier of a specific subject_type from having any claims that are not described in the subject_type. This prevents higher-level specs from proposing any additional claims to be included in subject identifiers of subject types that are defined in the Subject Identifier spec.
>>  
>> SPAGs:
>> Subject Principal Administrative Groupings or SPAGs are an addition to the OpenID "Shared Signals and Events Profile of SETs" <https://bitbucket.org/openid/risc/src/caep-draft-01/openid-sse-profile-2_0.txt>, which is a revision of the "RISC Profile of SETs <https://bitbucket.org/openid/risc/src/master/openid-risc-profile-1_0.txt>". The present draft of the SecEvents Subject Identifiers spec is derived from a section in this RISC Profile. The SSE Profile now refers to the SecEvents Subject Identifiers draft.
>> 
>> Minimal Change to the present Subject Identifiers draft: Remove the words "or not described" on line 247 <https://github.com/richanna/secevent/blob/1fd045d251ff3c6be9a500c6a78d895be3c6b2bf/draft-ietf-secevent-subject-identifiers.txt#L247>. This way a higher-level spec that needs to add additional attributes to all subject identifiers used in that spec can add them and specify the additional attributes' optional or required nature. In this option, SPAGs will be defined in the SSE profile spec.
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 10 Dec 2020 15:47:10 -0800

Hi Atul

I echo Phil's concerns wrt. multi subject SecEvents.

FYI: I am more interested in understanding the use cases so that we can
explore the various solutions than review your proposed changes. A SAML
subject type makes sense to me as it is another subject identifier that is
commonly used.

wrt. SPAG -- another option would be to wrap the secevent object in a SPAG
object -- this would also enable binding multiple secevents together.

Given what I understand of the use case, where one channel is being used to
exchange SecEvents that belong to different transmitters and senders,
wrapping the SecEvent preserves the semantics of a SecEvent, and the SPAG
wrapper identifiers the SPAG on the channel. Would that not work?

/Dick
ᐧ

---

From: Atul Tulshibagwale <[email-masked]>
Date: Tue, 15 Dec 2020 15:41:53 -0800

Hi Dick,
Ideally, we would be able to discuss the complexity of SecEvent tokens and
whether SPAG belongs in a subject-identifier separately. However in this
case they seem somewhat intertwined. Nevertheless, I'm limiting my response
with the assumption that there is only one subject claim in a SecEvent.

Right now, restricting a SecEvent to be about one SPAG can work for the
events we have real use-cases for in SSE. We will still need SPAG as a
subject type of its own for control plane SecEvents, but we can define that
in the SSE spec if it is too specialized of a use case for the general
SecEvents Subject Identifiers spec.

That said, I'd like us to focus on what it means to have a "spag_id" claim
within a subject identifier. The way I see it, SPAGs basically capture the
namespace separation for referring to subjects that may otherwise be
ambiguous.

If we do not allow for adding SPAGs to the spec, we are basically saying to
multi-tenanted hosts that need such separation to always use the "iss-sub"
subject_type and form their own pseudo-standard of how to differentiate
between subject principals that belong to different SPAGs. I can think of
transmitters defining a URL pattern for the "iss" claim that can be parsed
to figure out the sub-organization that the "sub" is about. It'll work, but
the opportunity to standardize something that many transmitters and
receivers need is lost.

So, even if we do not think we should add SPAGs to the spec right now, I
feel we should not preclude higher-level specs from adding such common
claims as SPAGs (i.e. the option #2 in my first email).

Thanks,
Atul

On Thu, Dec 10, 2020 at 3:47 PM Dick Hardt <[email-masked]> wrote:

> Given what I understand of the use case, where one channel is being used
> to exchange SecEvents that belong to different transmitters and senders,
>> Earlier, I had proposed that a subject identifier of any subject_type
>> have an optional common claim named "subject_category", which could
>> identify the type of subject principal the subject identifier refers to.
>> However, since the future of this request in the Subject Identifiers spec
>> wasn't clear, we decided to add a new "subject_type" in the SSE spec,
>> called "user-device-session". The SSE spec draft defines the algorithm to
>> figure out the category of the subject principal based on the content of
>> this subject identifier.
>>
>>>>    2. A SPAG may be a new subject type of its own when it is used in
>>>>    an event that specifies the starting or stopping of a stream.
>>>>
>>>> *Options*:
>>>>    1. *Minimal Change to the present Subject Identifiers draft*:
>>>>    Remove the words "or not described" on line 247
>>>>    2. *Include SPAGs in the Subject Identifiers spec*: Include
>>>>    language for SPAGs proposed earlier in this list, so that: