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

[Tim Cappalli <[e-mail]>]

Hey Phil, sorry for the delay on this. We've been discussing this in the OpenID SSE group as well.

We have concerns about receivers/RPs in CAEP/RISC needing to understand what are essentially identical event types just to delineate a user vs a device subject (as an example). There are also scalability concerns with having to send multiple events to convery this information. The scale we're talking about here is hundreds of millions of "subjects" (users, devices, sessions, applications, workloads).

For a basic revocation use case, if we don't have the ability to include multiple subjects and include a subject category, instead of an RP/receiver needing to know about a single event type of "all-sessions-revoked", we now need a minimum of 4 event types (device-session-revoked, user-session-revoked, session-revoked, all-sessions-revoked). This grows exponentially with new event types and makes it difficult to maintain in large scale environments with thousands of RPs/receivers.


We had discussed potentially using the subject_alias option, but we can't due to the user and device not being the same "entity".
3.5 > "Each Subject Identifier in the array MUST identify the same entity."

Here's an example of what we're trying to signal:

{
  "iss": "https://sts.windows.net/2d1ae189-3d85-44cf-8437-26fba424feaf/",
  "jti": "756E69717565206964656E746966696572",
  "iat": 1597158239,
  "aud": "https://outlook.office365.com/",
  "events": {
    "https://schemas.openid.net/secevent/caep/event-type/all-sessions-revoked": {
      "subject": [
        {
          "subject_type": "email",
          "email": "[e-mail]",
          "subject_category": "user"
        },
        {
          "subject_type": "iss-sub",
          "iss": "https://sts.windows.net/2d1ae189-3d85-44cf-8437-26fba424feaf/",
          "sub": "404ea68b-8b82-4e8c-876e-e936995238a3",
          "subject_category": "device"
        },
        {
          "subject_type": "iss-sub",
          "iss": "https://sts.windows.net/2d1ae189-3d85-44cf-8437-26fba424feaf/",
          "sub": "07bdd8df-3bcd-4562-9ffc-5e355f7e8ba1",
          "subject_category": "device"
        },
        {
          "subject_type": "iss-sub",
          "iss": "https://sts.windows.net/2d1ae189-3d85-44cf-8437-26fba424feaf/",
          "sub": "573d9c1c-b4e0-4cac-8927-6d43691fa898",
          "subject_category": "user"
        }
      ]
    }
  }
}



Proposal:

Add a subject category with the following defined options:

  *   user
  *   device
  *   session
  *   application
  *   workload

If multiple subjects are present, it is expected that the event applies to all of the subjects to the extent that it makes sense to the event type.


Open question and discussion items:

1) Can "subject" be an array of multiple subjects that are not the same entity?

1a) If so, how should alias be combined with multiple subjects? In the example above, both user subjects would be aliases of each other.

2) If no category is provided, what should be the default?

tim



________________________________
From: Id-event <[e-mail]> on behalf of Phil Hunt <[e-mail]>
Sent: Monday, July 13, 2020 17:55
To: Atul Tulshibagwale <atultulshi=[e-mail]>
Cc: ID Events Mailing List <[e-mail]>; Dick Hardt <[e-mail]>
Subject: Re: [Id-event] Subject Categories in Subject Identifiers

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



On Jul 13, 2020, at 1:47 PM, Atul Tulshibagwale <atultulshi=[e-mail]<mailto: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.

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=a0c347c8-a1ba-4e79-9053-3777ea432a51]ᐧ

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frichanna%2Fsecevent%2Fpull%2F1&data=02%7C01%7Ctim.cappalli%40microsoft.com%7C7bcfca04cdaa4d4e5a8708d8277794dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302741847522566&sdata=Y6lYo3GB6OZ2Nl661DPdAqcdKk%2BSVOxXOjbGL%2FWSX84%3D&reserved=0>)..

Thanks,
Atul

_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/id-event<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fid-event&data=02%7C01%7Ctim.cappalli%40microsoft.com%7C7bcfca04cdaa4d4e5a8708d8277794dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302741847532516&sdata=TsKEtiF7LqED8Cqqx9T0ZFIRtBZaBz1dSt02gtMWAA4%3D&reserved=0>
_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/id-event<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fid-event&data=02%7C01%7Ctim.cappalli%40microsoft.com%7C7bcfca04cdaa4d4e5a8708d8277794dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302741847532516&sdata=TsKEtiF7LqED8Cqqx9T0ZFIRtBZaBz1dSt02gtMWAA4%3D&reserved=0>
_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/id-event