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

[Phil Hunt <[e-mail]>]

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
[e-mail]



> On Jul 13, 2020, at 1:47 PM, Atul Tulshibagwale <atultulshi=[e-mail]> wrote:
> 
> 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
> 
> On Mon, Jul 13, 2020 at 11:25 AM Dick Hardt <[e-mail] <mailto:[e-mail]>> wrote:
> 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=[e-mail] <mailto:[e-mail]>> 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
> 
> _______________________________________________
> Id-event mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
> _______________________________________________
> Id-event mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event