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

From: Tim Cappalli <[email-masked]>
Date: Tue, 11 Aug 2020 15:44:04 +0000

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": "[email-masked]",
          "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 <[email-masked]> on behalf of Phil Hunt <[email-masked]>
Sent: Monday, July 13, 2020 17:55
To: Atul Tulshibagwale <atultulshi=[email-masked]>
Cc: ID Events Mailing List <[email-masked]>; Dick Hardt <[email-masked]>
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
[email-masked]<mailto:[email-masked]>

On Jul 13, 2020, at 1:47 PM, Atul Tulshibagwale <atultulshi=[email-masked]<mailto:atultulshi=[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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=[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://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
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

---

From: Phil Hunt <[email-masked]>
Date: Tue, 11 Aug 2020 16:34:23 -0700

Tim,

Thanks for getting back to me.

I worry bringing multi-subject dimensionality to SET could have a lot of negative consequences.  This is similar to the discussion we had in the WG about bundling multiple event URIs in the same SET and the complexity that might cause.

I think there is a PII concern that the RP can correlate multiple identifiers it might not know about. Having only 1 subject identifier implies sender and receiver have a mutual understanding about the subject that was likely previously authorized by the subject.

Introducing multiple subjects may introduce binding artifacts that undermine the idea that shared signals enables cross-domain decoupling.  Multiplicity may introduce permutation and combination effects upon the receiver that may not be workable. 

If you think it is important to express the idea that a series of SETs are in fact related (e.g. all items related to a user are revoked including sessions, tokens, authorization, are to be revoked), the “txn” claim can be used for this purpose. “txn” lets an issuer indicate that a set of Events stem from the same transaction (aka event).

Phillip Hunt
[email-masked]

> On Aug 11, 2020, at 8:44 AM, Tim Cappalli <[email-masked]> wrote:
> 
>   "iss": "https://sts.windows.net/2d1ae189-3d85-44cf-8437-26fba424feaf/ <https://sts.windows.net/2d1ae189-3d85-44cf-8437-26fba424feaf/>",
>   "aud": "https://outlook.office365.com/ <https://outlook.office365.com/>",
>   "events": {
>     "https://schemas.openid.net/secevent/caep/event-type/all-sessions-revoked <https://schemas.openid.net/secevent/caep/event-type/all-sessions-revoked>": {
>       "subject": [
>         {
>           "subject_type": "email",
>           "email": "[email-masked] <mailto:[email-masked]>",
>           "iss": "https://sts.windows.net/2d1ae189-3d85-44cf-8437-26fba424feaf/ <https://sts.windows.net/2d1ae189-3d85-44cf-8437-26fba424feaf/>",
>           "iss": "https://sts.windows.net/2d1ae189-3d85-44cf-8437-26fba424feaf/ <https://sts.windows.net/2d1ae189-3d85-44cf-8437-26fba424feaf/>",
>           "iss": "https://sts.windows.net/2d1ae189-3d85-44cf-8437-26fba424feaf/ <https://sts.windows.net/2d1ae189-3d85-44cf-8437-26fba424feaf/>",
> user
> device
> session
> application
> workload
> From: Id-event <[email-masked] <mailto:[email-masked]>> on behalf of Phil Hunt <[email-masked] <mailto:[email-masked]>>
> To: Atul Tulshibagwale <atultulshi=[email-masked] <mailto:atultulshi=[email-masked]>>
> Cc: ID Events Mailing List <[email-masked] <mailto:[email-masked]>>; Dick Hardt <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
>> On Jul 13, 2020, at 1:47 PM, Atul Tulshibagwale <atultulshi=[email-masked] <mailto:atultulshi=[email-masked]>> wrote:
>> 
>> 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.
>> 
>> 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,
>> 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
>> 
>> [email-masked] <mailto:[email-masked]>
>> 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>
>> [email-masked] <mailto:[email-masked]>
>> 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>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>