Subject: [Id-event] Subject Categories in Subject Identifiers

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

Hi all,
Subject Identifiers will be used in various specifications about events
pertaining to those subject identifiers. In order to determine the scope of
the event, it is important to know what the transmitter of the event that
includes the subject identifier refers to.

For example, when a subject identifier specifies a phone number as the
identifier, is the transmitter of the event that includes such a subject
identifier specifying the user or the device represented by the subject
identifier.

Since this is a property of the subject rather than the event, it should be
logically included in the subject identifier spec. Therefore, I'm proposing
that we include a "subject category" claim within the subject identifier.
The subject category could have one of the following values:

   - *User*
   - *Device*
   - *Session*

The above values are sufficient for the SSE profile, but other values may
be possible (although such a possibility is not a part of my proposal
<https://github.com/richanna/secevent/pull/1>).

Thanks,
Atul

---

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

Hi Atul

I don't follow why this statement is true:

"Since this is a property of the subject rather than the event"

I would come to the opposite conclusion.

ᐧ

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

> Since this is a property of the subject rather than the event, it should
> be logically included in the subject identifier spec. Therefore, I'm
> proposing that we include a "subject category" claim within the subject
> identifier. The subject category could have one of the following values:
>
>    - *User*
>    - *Device*
>    - *Session*
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>

---

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

To address Mike's point I'm clarifying the proposal syntax here.

I'm proposing that we add a "categories" claim to subject identifiers,
regardless of the subject-identifier type (i.e. a common claim), with the
following text:

Subject Categories

   Subjects may be categorized as users, devices or sessions.  To

   specify the category of a subject, a "category" claim MAY be

   included.  If present, the claim MUST have a value that is one of:

   user  Specifies that the subject category is a user.

   device  Specifies that the subject category is a device.

   session  Specifies that the subject category is a session.

To address Dick's question:
I suppose one could think of it either way. I am neutral to adding it
within subject identifiers or at a higher-level in the event that includes
the subject identifier claim. This was also a point of discussion in the
SSE working group, so I'll let others comment on this. This may be dropped
if no one has strong reasons to include it in the subject identifiers claim.

Thanks,
Atul

---

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

Why is the category not part of the eventuri / event definition?  Why have one event that applies to a session, a device, a person, and an account at the same time as opposed to 4 different event uris?

It feels like you may be trying define a  combined, multi-purpose event to cover many actual events. Is that the goal?

My expectation for defining SETs and eventuris was that the eventuri conveys 90% of the information content of a SET. The subject identifier indicates who or what the event is about and the occasional use of payload claims to provide “useful” additional information (like a counter).  E.g. if you want to convey how many account resets and not just the fact the account was reset. It makes sense to re-use the same URI even though the actions taken on the 3rd reset might be different then on the first.

IMO, a wide number of event uris paired with lightweight SETs means policy systems and SET routers can make quick decisions on where and how to act upon an event for a particular subject.

Phillip Hunt
[email-masked]

> On Jul 13, 2020, at 1:47 PM, Atul Tulshibagwale <atultulshi=[email-masked]> wrote:
> 
> I'm proposing that we add a "categories" claim to subject identifiers, regardless of the subject-identifier type (i.e. a common claim), with the following text:
> Subject Categories
> 
> I suppose one could think of it either way. I am neutral to adding it within subject identifiers or at a higher-level in the event that includes the subject identifier claim. This was also a point of discussion in the SSE working group, so I'll let others comment on this. This may be dropped if no one has strong reasons to include it in the subject identifiers claim.
> 
> Thanks,
> Atul
> 
> On Mon, Jul 13, 2020 at 11:25 AM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Atul
> 
> On Mon, Jul 13, 2020 at 9:10 AM Atul Tulshibagwale <atultulshi=[email-masked] <mailto:[email-masked]>> wrote:
> Hi all,
> Subject Identifiers will be used in various specifications about events pertaining to those subject identifiers. In order to determine the scope of the event, it is important to know what the transmitter of the event that includes the subject identifier refers to.
> 
> For example, when a subject identifier specifies a phone number as the identifier, is the transmitter of the event that includes such a subject identifier specifying the user or the device represented by the subject identifier.
> 
> Since this is a property of the subject rather than the event, it should be logically included in the subject identifier spec. Therefore, I'm proposing that we include a "subject category" claim within the subject identifier. The subject category could have one of the following values:
> User
> Device
> Session
> The above values are sufficient for the SSE profile, but other values may be possible (although such a possibility is not a part of my proposal <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>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>