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

Phil Hunt <phil.hunt@independentid.com> Tue, 11 August 2020 23:34 UTC

Return-Path: <phil.hunt@independentid.com>
X-Original-To: id-event@ietfa.amsl.com
Delivered-To: id-event@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505783A0DD0 for <id-event@ietfa.amsl.com>; Tue, 11 Aug 2020 16:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.785
X-Spam-Level:
X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVhSfv3oXk27 for <id-event@ietfa.amsl.com>; Tue, 11 Aug 2020 16:34:25 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874F43A0D77 for <id-event@ietf.org>; Tue, 11 Aug 2020 16:34:25 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id 17so59392pfw.9 for <id-event@ietf.org>; Tue, 11 Aug 2020 16:34:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=em6ojSJs8M7rUDoZM5mg53gMxD59xfAbnhwSuoEAWmU=; b=CQ5M9UxrbhG2QBghUO2v5xolvzmNY1gBOJzFzf7oc0HVaS1CARenwrySpwaGubUu4Z AzbYKyfYHBJJxJ3izpwKfmfxbb8fL21wSqw24H7WzdLFDYtm8UyxD+p1UknCGiirmOj2 HMR1yKW6y8a/nTIsQdvEfWjk8Ua9rzq8pXVceDTOVeRfLCUN0Zcsnta1AGRnjfqNNwBW 12I4WjE15HISDpLcOXZ53f5OkaIM7YEAdXwnYS6XeXFMAitg1xhkel48lF0nVwyV5gob ysDlvbJk75e3y4vi+pOYljt954COVNMpHgaFGtODpmKJowOflYX/P7Z1312IhtdBax+F NCeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=em6ojSJs8M7rUDoZM5mg53gMxD59xfAbnhwSuoEAWmU=; b=naVgBvzgWF84UCNsEty01e/TMw2u2AYsc8Zzh7ICeA89Y0e1XrSOf8S1bfEEuTCDwC OA9Kbjx0fFKRWJ+uTv91eZntg6lF5GYrSSdu1VTQ//6KvamJsg3bMMN4Ga+tYLROVNmB P8NzGQHLeBOixK0HOyFK3lRrFO9GTSLU8znJGBXvkxgTu9NG4p1RPptlRg0a9Shu+NMe njcpuL/3nQBovxB8g5TwWTFJe7bjH9sQ8gCksiKuU51TBuDCIHfCyLB6Ohtx1CwXiwtQ xhY104hYxeRv3RL5egjYF5DNWETLw/7eEiTigBCGB1ik088QxlduepX6BBM+6yLBjGap 6ohA==
X-Gm-Message-State: AOAM533yZqiVbDRZVQbN2Z6rAy7nQ97zFHsYCScpwUOtP8FGzpzjLhWo ZEGe5iSGc6E2HdODGwHnimtwKw==
X-Google-Smtp-Source: ABdhPJwEYtNje9kpxrPePZRtgWrIbZNhtfwsYmOiqiU9RFipmIHKaur47FNTElKDp6Eq+9Fl2oi39g==
X-Received: by 2002:aa7:9813:: with SMTP id e19mr8544202pfl.285.1597188864558; Tue, 11 Aug 2020 16:34:24 -0700 (PDT)
Received: from node-1w7jr9qqo6k568f59thk6ol0s.ipv6.telus.net (node-1w7jr9qqo6k568f59thk6ol0s.ipv6.telus.net. [2001:569:79bc:100:3d8b:f0d9:348a:666c]) by smtp.gmail.com with ESMTPSA id y1sm177082pfr.207.2020.08.11.16.34.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2020 16:34:23 -0700 (PDT)
From: Phil Hunt <phil.hunt@independentid.com>
Message-Id: <09677E12-D17E-47DA-8FC3-A434B90B3148@independentid.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7088B8B7-ED93-4C6C-9380-FC6890171A2E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 11 Aug 2020 16:34:23 -0700
In-Reply-To: <MN2PR00MB0893B4D1347E71A7B18AFD8095451@MN2PR00MB0893.namprd00.prod.outlook.com>
Cc: ID Events Mailing List <id-event@ietf.org>
To: Tim Cappalli <Tim.Cappalli@microsoft.com>
References: <CAMCkG5uxCRUPKgbM-XsWmykpvSbjpXybWew=brs4GTNwmQQyQQ@mail.gmail.com> <CAD9ie-tXCtxQK9XPX6JBMnY2Byi=STGh7gzwMho88KqH6zG_vw@mail.gmail.com> <CAMCkG5s3zgR=cMdXQ=Ct+KTcUFpLVNL2+DxUpMzx66NAG6o+bQ@mail.gmail.com> <5C854271-BC02-47EE-814C-D8270681BF33@independentid.com> <MN2PR00MB0893B4D1347E71A7B18AFD8095451@MN2PR00MB0893.namprd00.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/S2W-GrS1OoBxiL5HNRwpJX5odWM>
Subject: Re: [Id-event] Subject Categories in Subject Identifiers
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." <id-event.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/id-event>, <mailto:id-event-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/id-event/>
List-Post: <mailto:id-event@ietf.org>
List-Help: <mailto:id-event-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/id-event>, <mailto:id-event-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2020 23:34:28 -0000

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
phil.hunt@independentid.com



> On Aug 11, 2020, at 8:44 AM, Tim Cappalli <Tim.Cappalli@microsoft.com> wrote:
> 
> 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/ <https://sts.windows.net/2d1ae189-3d85-44cf-8437-26fba424feaf/>",
>   "jti": "756E69717565206964656E746966696572",
>   "iat": 1597158239,
>   "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": "tim@microsoft.com <mailto:tim@microsoft.com>",
>           "subject_category": "user"
>         },
>         {
>           "subject_type": "iss-sub",
>           "iss": "https://sts.windows.net/2d1ae189-3d85-44cf-8437-26fba424feaf/ <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/ <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/ <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 <id-event-bounces@ietf.org <mailto:id-event-bounces@ietf.org>> on behalf of Phil Hunt <phil.hunt@independentid.com <mailto:phil.hunt@independentid.com>>
> Sent: Monday, July 13, 2020 17:55
> To: Atul Tulshibagwale <atultulshi=40google.com@dmarc.ietf.org <mailto:atultulshi=40google.com@dmarc.ietf.org>>
> Cc: ID Events Mailing List <id-event@ietf.org <mailto:id-event@ietf.org>>; Dick Hardt <dick.hardt@gmail.com <mailto:dick.hardt@gmail.com>>
> 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
> phil.hunt@independentid.com <mailto:phil.hunt@independentid.com>
> 
> 
> 
>> On Jul 13, 2020, at 1:47 PM, Atul Tulshibagwale <atultulshi=40google.com@dmarc.ietf.org <mailto:atultulshi=40google.com@dmarc.ietf.org>> 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 <dick.hardt@gmail.com <mailto:dick.hardt@gmail.com>> 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=40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org>> 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
>> Id-event@ietf.org <mailto:Id-event@ietf.org>
>> 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
>> Id-event@ietf.org <mailto:Id-event@ietf.org>
>> 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
>> Id-event@ietf.org <mailto:Id-event@ietf.org>
>> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>