Subject: [Id-event] Subject Principals and Subject Principal Administrative Groupings

From: Atul Tulshibagwale <[email-masked]>
Date: Mon, 13 Jul 2020 09:01:13 -0700

Hi all,
Here's a quick background for the proposal
<https://github.com/richanna/secevent/pull/1> for including Subject
Principals and Subject Principal Administrative Groupings or SPAGs in the
Subject Identifiers spec.

*Use of Subject Identifiers in Shared Signals and Events*:
The Shared Signals and Events (SSE) profile of SETs specifies that
transmitters and receivers send and receive SETs that contain Subject
Identifiers. These subject identifiers have the format that is now being
discussed as a separate specification here.

*Transmitters and Receivers in SSE*
The SSE profile defines transmitters and receivers as hosts that manage
streams between peers. The receiver authenticates to the transmitter using
OAuth, requiring the use of a secret per receiver. In a multi-tenanted host
that handles hundreds of thousands or millions of independent tenants,
maintaining such a secret per instance of a receiver is cumbersome.
Furthermore, since a transmitter and a receiver has to maintain a stream
per pair, creating such per-tenant streams can add significant
implementation overhead.

*SPAGs*
Therefore, we need a notion of a grouping of subjects within the same
transmitter and receiver to distinguish between various administrative
groupings that exist within a host. These groupings could include tenants,
organizational units or user groups. This grouping is captured in the
notion of a SPAG. The uniqueness of a user identifier (subject identifier)
may also be limited to a SPAG. For example, if a random unique ID
represents a user, then that ID may be unique within a SPAG and not
universally across a transmitter or receiver. This is because each
transmitter and receiver may have multiple connections to other
transmitters and receivers, and ensuring uniqueness across all such peers
is probably an intractable problem.

*Subject Principals*
While what is represented within a subject identifier may be only an aspect
of the management entity, the administrative grouping is about the
management entity itself. This could be the user, device or other principal
that the subject identifier represents. Therefore, an abstract notion of a
Subject Principal is also required in order specify what the grouping
within a SPAG is about.

The above is captured in the "Subject Principal" and "SPAG" sections within
the proposed PR <https://github.com/richanna/secevent/pull/1>.

Thanks,
Atul

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Jul 2020 11:31:24 -0700

To clarify, your proposal is driven by the implementation burden of
maintaining separate secrets / streams between a transmitter and receiver?
ᐧ

On Mon, Jul 13, 2020 at 9:01 AM Atul Tulshibagwale <atultulshi=
[email-masked]> wrote:

> While what is represented within a subject identifier may be only an
> aspect of the management entity, the administrative grouping is about the
> The above is captured in the "Subject Principal" and "SPAG" sections
> within the proposed PR <https://github.com/richanna/secevent/pull/1>.
>
> Thanks,
> Atul
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>

---

From: Atul Tulshibagwale <[email-masked]>
Date: Mon, 13 Jul 2020 14:08:29 -0700

Dick, your understanding is correct.

To clarify the proposal here, Here's the text I'm proposing to be added:

3.  Subject Principals

   Subject Principals are the management entities associated with
   Subjects.  These may be human or robotic principals or devices or
   other entities that are managed by transmitters and receivers.  For
   example, the same Subject Principal may be referred to by an email
   address or a phone number.  A transmitter or receiver will typically
   manage subject principals and organize them into sub-groupings such
   as tenants, groups, organizational units, etc.

   Subjects are identified by Subject Identifiers defined below.

3.1.  SPAGs

   Subject Principals MAY be grouped for administrative purposes into
   "Subject Principal Administrative Groupings" or SPAGs.  For example,
   all users belonging to one customer of a "multi-tenanted" Transmitter
   may be in one SPAG.  Alternatively, an Organizational Unit or a group
   of Subjects within a customer of a Transmitter (whether multi-
   tenanted or not) may be one SPAG.  SPAGs may have overlapping sets of
   Subjects.

   A SPAG MAY be the Subject of certain stream update events defined
   later in this spec, hence is defined as a Subject Type of its own
   below.  A SPAG identifier MAY be included in other subject types to
   disambiguate the subject.

   A SPAG subject identifier is agreed to offline between a transmitter
   and a receiver.

The benefits of doing this are:

   1. Multi-tenanted hosts do not need to maintain secrets per tenant and
   per transmitter tenant if each tenant has to be an event transmitter and an
   event receiver of its own.
   2. An event stream may be established between two multi-tenanted hosts,
   and so does not need to be managed at a per-tenant level
   3. The same subject or subject principal may be a part of multiple
   SPAGs, and identifying the SPAG that an event relates to can be achieved if
   the standard allows for the SPAGs to be identified.

On Mon, Jul 13, 2020 at 11:32 AM Dick Hardt <[email-masked]> wrote:

> [email-masked] <40google.com@dmarc..ietf.org>> wrote:
>
>> Hi all,
>> organizational units or user groups.. This grouping is captured in the

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Jul 2020 14:34:14 -0700

I see the SPAG lets the transmitter and receiver provide context, as the
subject identifier may be the same across SPAGs.

Now I'm trying to understand how the transmitter authenticates to the
receiver if it does not have it's own secret (assuming that authentication
model) -- IE, how does the receiver know the transmitter is authorized for
that SPAG?

On Mon, Jul 13, 2020 at 2:08 PM Atul Tulshibagwale <[email-masked]>
wrote:

>    2. An event stream may be established between two multi-tenanted
>    hosts, and so does not need to be managed at a per-tenant level

---

From: Phil Hunt <[email-masked]>
Date: Mon, 13 Jul 2020 15:03:35 -0700

Atul,

I not understanding why a receiver needs to differentiate between an OP issuer of a subject and a SPAG?

What is the difference?

Are we talking about an event from a relying party adminitrator domain?  

E.g. Phil Hunt’s Azure issued OP account used within the Google adminstratvie domain had this event?

Could the receiver not already figure this our by noting that the issuer of the SET is not the issuer of the subject identifier?

Phillip Hunt
[email-masked]

> On Jul 13, 2020, at 2:08 PM, Atul Tulshibagwale <atultulshi=[email-masked]> wrote:
> 
> Multi-tenanted hosts do not need to maintain secrets per tenant and per transmitter tenant if each tenant has to be an event transmitter and an event receiver of its own.
> An event stream may be established between two multi-tenanted hosts, and so does not need to be managed at a per-tenant level
> The same subject or subject principal may be a part of multiple SPAGs, and identifying the SPAG that an event relates to can be achieved if the standard allows for the SPAGs to be identified.
> 
> 
> On Mon, Jul 13, 2020 at 11:32 AM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> To clarify, your proposal is driven by the implementation burden of maintaining separate secrets / streams between a transmitter and receiver?
> ᐧ
> 
> On Mon, Jul 13, 2020 at 9:01 AM Atul Tulshibagwale <atultulshi=[email-masked] <mailto:40google.com@dmarc..ietf.org>> wrote:
> Hi all, 
> Here's a quick background for the proposal <https://github.com/richanna/secevent/pull/1> for including Subject Principals and Subject Principal Administrative Groupings or SPAGs in the Subject Identifiers spec.
> 
> Use of Subject Identifiers in Shared Signals and Events:
> The Shared Signals and Events (SSE) profile of SETs specifies that transmitters and receivers send and receive SETs that contain Subject Identifiers. These subject identifiers have the format that is now being discussed as a separate specification here.
> 
> Transmitters and Receivers in SSE
> The SSE profile defines transmitters and receivers as hosts that manage streams between peers. The receiver authenticates to the transmitter using OAuth, requiring the use of a secret per receiver. In a multi-tenanted host that handles hundreds of thousands or millions of independent tenants, maintaining such a secret per instance of a receiver is cumbersome. Furthermore, since a transmitter and a receiver has to maintain a stream per pair, creating such per-tenant streams can add significant implementation overhead.
> 
> SPAGs
> Therefore, we need a notion of a grouping of subjects within the same transmitter and receiver to distinguish between various administrative groupings that exist within a host. These groupings could include tenants, organizational units or user groups.. This grouping is captured in the notion of a SPAG. The uniqueness of a user identifier (subject identifier) may also be limited to a SPAG. For example, if a random unique ID represents a user, then that ID may be unique within a SPAG and not universally across a transmitter or receiver. This is because each transmitter and receiver may have multiple connections to other transmitters and receivers, and ensuring uniqueness across all such peers is probably an intractable problem.
> 
> Subject Principals
> While what is represented within a subject identifier may be only an aspect of the management entity, the administrative grouping is about the management entity itself.. This could be the user, device or other principal that the subject identifier represents. Therefore, an abstract notion of a Subject Principal is also required in order specify what the grouping within a SPAG is about.
> 
> The above is captured in the "Subject Principal" and "SPAG" sections within the proposed PR <https://github.com/richanna/secevent/pull/1>.
> 
> Thanks,
> Atul
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>

---

From: Atul Tulshibagwale <[email-masked]>
Date: Mon, 13 Jul 2020 15:05:38 -0700

That could be true but there are a few ways in which it can be avoided:

   1. The peers leverage some higher-level trust to accept / decline events
   relating to lower level SPAGs. For example, if trust is established at a
   tenant level, then an OU level SPAG need not have its own authorization.
   2. The secret required for establishing the authorization of a SPAG may
   be temporary. For example:
      1. An administrator signs in to their tenant in the transmitter's
      administrator console
      2. The admin obtains a temporary authorization (one-time code)
      3. The admin signs in to their tenant in the receiver's
      administration console and pastes in the one-time code
      4. The receiver sends a request to enable the stream for the
      specified SPAG with that one-time authorization.

In the first case, there are no additional secrets required. In the second
case, the secret is temporary.

On Mon, Jul 13, 2020 at 2:34 PM Dick Hardt <[email-masked]> wrote:

>>    1. Multi-tenanted hosts do not need to maintain secrets per tenant
>>    and per transmitter tenant if each tenant has to be an event transmitter
>>    and an event receiver of its own.

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Jul 2020 15:25:07 -0700

Would a transmitter that is only in one SPAG (a single tenant system) have
to include its SPAG id in events sent to a receiver that accepts events
from multiple SPAGs? But it would not include it in sending events to other
receivers that have separate credentials for each relationship?

ᐧ

On Mon, Jul 13, 2020 at 3:05 PM Atul Tulshibagwale <[email-masked]>
wrote:

>    1. The peers leverage some higher-level trust to accept / decline
>    events relating to lower level SPAGs. For example, if trust is established
>    at a tenant level, then an OU level SPAG need not have its own
>    authorization.
>    2. The secret required for establishing the authorization of a SPAG
>    may be temporary. For example:
>>>>> The SSE profile defines transmitters and receivers as hosts that
>>>>> manage streams between peers. The receiver authenticates to the transmitter
>>>>> using OAuth, requiring the use of a secret per receiver. In a
>>>>> multi-tenanted host that handles hundreds of thousands or millions of
>>>>> independent tenants, maintaining such a secret per instance of a receiver
>>>>> is cumbersome. Furthermore, since a transmitter and a receiver has to
>>>>> maintain a stream per pair, creating such per-tenant streams can add
>>>>> significant implementation overhead.
>>>>>
>>>>> *SPAGs*

---

From: Atul Tulshibagwale <[email-masked]>
Date: Mon, 13 Jul 2020 15:33:05 -0700

Hi Phil,
Not sure I fully grasp your question, but let me address the part I
understood:

I'm assuming "OP" means "OAuth Provider". It's true that the "iss-sub"
subject type may be used in place of a SPAG, wherein the "iss" claim
identifies the SPAG. There are a few issues with this:

   1. Transmitters and receivers will have to come up with (proprietary)
   ways of encoding SPAGs at various levels. Each one may not have their own
   OAuth provider (one reason why we need a SPAG), so the "iss" URL may be
   constructed as some sub-space of the OAuth provider URL.
   2. All subject-types would have to be of "iss-sub" type, and
   transmitters and receivers would have to define their own proprietary ways
   of interpreting the content of a "sub" claim. For example, if one wanted to
   use email as a subject type, they would:
      - Use the "iss-sub" subject type
      - Encode the SPAG in the "iss" claim
      - Encode the email address in the "sub" claim as say: "
      email:[email-masked]"

Just to clarify: A SPAG may not just be a tenant-id, it could be an OU or a
group within a tenant (or a host in case of a single-tenant system)

Not sure I understand the question about the "event from a relying party
administrator domain". I think we are talking about the same thing (tenant
= administrator domain), but the tenant may exist in the issuer and the
relying party.

The issuer of the SETs may be the same for a large number of tenants.

On Mon, Jul 13, 2020 at 3:03 PM Phil Hunt <[email-masked]>
wrote:

> Could the receiver not already figure this our by noting that the issuer
> of the SET is not the issuer of the subject identifier?
>
> Phillip Hunt
> On Jul 13, 2020, at 2:08 PM, Atul Tulshibagwale <
> atultulshi=[email-masked]> wrote:
>
>>> management entity itself.. This could be the user, device or other
>>> principal that the subject identifier represents. Therefore, an abstract
>>> notion of a Subject Principal is also required in order specify what the
>>> grouping within a SPAG is about.
>>>

---

From: Atul Tulshibagwale <[email-masked]>
Date: Mon, 13 Jul 2020 15:33:29 -0700

Not required, since the claim is optional.

On Mon, Jul 13, 2020 at 3:25 PM Dick Hardt <[email-masked]> wrote:

>> In the first case, there are no additional secrets required. In the
>> second case, the secret is temporary.
>>
>>
>>
>>> On Mon, Jul 13, 2020 at 2:08 PM Atul Tulshibagwale <
>>> [email-masked]> wrote:
>>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Jul 2020 15:37:21 -0700

Which part is not required?

On Mon, Jul 13, 2020 at 3:33 PM Atul Tulshibagwale <[email-masked]>
wrote:

>> Would a transmitter that is only in one SPAG (a single tenant system)
>> have to include its SPAG id in events sent to a receiver that accepts
>> events from multiple SPAGs? But it would not include it in sending events
>> to other receivers that have separate credentials for each relationship?
>>
>>
>>
>> ᐧ
>>
>>>> I see the SPAG lets the transmitter and receiver provide context, as
>>>> the subject identifier may be the same across SPAGs.
>>>>
>>>>>>> Therefore, we need a notion of a grouping of subjects within the
>>>>>>> same transmitter and receiver to distinguish between various administrative

---

From: Atul Tulshibagwale <[email-masked]>
Date: Mon, 13 Jul 2020 15:54:07 -0700

Sorry for the terse message.

If a single tenant transmitter is trusted by a multi-tenanted receiver for
a specific tenant, then the SPAG-id need not be included if the subject is
unique at the tenant level, because the receiver will automatically
identify SPAG that the subject belongs to on its end (based on the
authentication).

On Mon, Jul 13, 2020 at 3:37 PM Dick Hardt <[email-masked]> wrote:

>>> On Mon, Jul 13, 2020 at 3:05 PM Atul Tulshibagwale <
>>>>       1. An administrator signs in to their tenant in the
>>>>       transmitter's administrator console
>>>>>>    1. Multi-tenanted hosts do not need to maintain secrets per
>>>>>>    tenant and per transmitter tenant if each tenant has to be an event
>>>>>>    transmitter and an event receiver of its own.
>>>>>>    3. The same subject or subject principal may be a part of
>>>>>>    multiple SPAGs, and identifying the SPAG that an event relates to can be
>>>>>>    achieved if the standard allows for the SPAGs to be identified.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> <https://github.com/richanna/secevent/pull/1> for including
>>>>>>>> Subject Principals and Subject Principal Administrative Groupings or SPAGs
>>>>>>>> in the Subject Identifiers spec.
>>>>>>>>
>>>>>>>> While what is represented within a subject identifier may be only
>>>>>>>> an aspect of the management entity, the administrative grouping is about
>>>>>>>> the management entity itself. This could be the user, device or other
>>>>>>>> The above is captured in the "Subject Principal" and "SPAG"
>>>>>>>> sections within the proposed PR
>>>>>>>> <https://github.com/richanna/secevent/pull/1>.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Atul
>>>>>>>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Jul 2020 16:00:44 -0700

So the receiver is using authentication sometimes to determine SPAG, and
not at other times?

I'm digging into this as I had always thought of the event being between
two parties, where they are identified by the endpoint and/or the
credentials.

Adding a relationship identifier seems to be solving the problem at the
wrong layer, unless it is in all events.

On Mon, Jul 13, 2020 at 3:54 PM Atul Tulshibagwale <[email-masked]>
wrote:

>>>>>    2. The secret required for establishing the authorization of a
>>>>>    SPAG may be temporary. For example:

---

From: Atul Tulshibagwale <[email-masked]>
Date: Mon, 13 Jul 2020 17:08:19 -0700

I am OK with making the spag_id a required claim in every subject
identifier. For single tenanted transmitters, it would be a constant value
for all events they generate.

On Mon, Jul 13, 2020 at 4:01 PM Dick Hardt <[email-masked]> wrote:

>> If a single tenant transmitter is trusted by a multi-tenanted receiver
>> for a specific tenant, then the SPAG-id need not be included if the subject
>> is unique at the tenant level, because the receiver will automatically
>>> On Mon, Jul 13, 2020 at 3:33 PM Atul Tulshibagwale <
>>>>>>> Now I'm trying to understand how the transmitter authenticates to
>>>>>>> the receiver if it does not have it's own secret (assuming that
>>>>>>> authentication model) -- IE, how does the receiver know the transmitter is
>>>>>>> authorized for that SPAG?
>>>>>>>
>>>>>>>
>>>>>>>>    2. An event stream may be established between two
>>>>>>>>    multi-tenanted hosts, and so does not need to be managed at a per-tenant
>>>>>>>>    level
>>>>>>>>> To clarify, your proposal is driven by the implementation burden
>>>>>>>>> of maintaining separate secrets / streams between a transmitter and
>>>>>>>>> receiver?
>>>>>>>>> ᐧ
>>>>>>>>>
>>>>>>>>>> The Shared Signals and Events (SSE) profile of SETs specifies
>>>>>>>>>> that transmitters and receivers send and receive SETs that contain Subject

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Jul 2020 17:12:48 -0700

Would different URLs for each relationship not solve your issue of
maintaining secrets for each SPAG? For example:

https:/example.com/secevent/SPAG_ID_1

https:/example.com/secevent/SPAG_ID_2

https:/example.com/secevent/SPAG_ID_3

Then the credential is independent of the SPAG, but we are not injecting an
identifier (spag_id) that is only relevant to orgs that want to use the
same credentials across SPAG relationships.

On Mon, Jul 13, 2020 at 5:08 PM Atul Tulshibagwale <[email-masked]>
wrote:

>>>>>>>    1. The peers leverage some higher-level trust to accept /
>>>>>>>    decline events relating to lower level SPAGs. For example, if trust is
>>>>>>>    established at a tenant level, then an OU level SPAG need not have its own
>>>>>>>    authorization.
>>>>>>>> I see the SPAG lets the transmitter and receiver provide context,
>>>>>>>> as the subject identifier may be the same across SPAGs.
>>>>>>>>
>>>>>>>>>>> While what is represented within a subject identifier may be
>>>>>>>>>>> only an aspect of the management entity, the administrative grouping is
>>>>>>>>>>> about the management entity itself. This could be the user, device or other