Re: [Id-event] Draft-06 issue re: subject principal grouping

Atul Tulshibagwale <atultulshi@google.com> Fri, 02 October 2020 23:14 UTC

Return-Path: <atultulshi@google.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 F2CF33A1743 for <id-event@ietfa.amsl.com>; Fri, 2 Oct 2020 16:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 fuj2FZCWOxhm for <id-event@ietfa.amsl.com>; Fri, 2 Oct 2020 16:14:04 -0700 (PDT)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 B85E83A1742 for <id-event@ietf.org>; Fri, 2 Oct 2020 16:14:04 -0700 (PDT)
Received: by mail-yb1-xb32.google.com with SMTP id x8so2284691ybe.12 for <id-event@ietf.org>; Fri, 02 Oct 2020 16:14:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6p6sM/wEMJMaWKqu8Fo57MKRbIIHP4AdJZkThoBGuAI=; b=X5niYhrGFLHIBEOvjUIanqwkOOBdhLVjlK9QaJfajAGkGnrcHJjwQEfac8PogGjaGS i6pkWphteOX3/xMAW+xr4039n83tLd+Po9jHyGxLFPafs9OCyZ1fUOS9n6yszxDt4AGp yAtKOElsBgayy6Ls/+wgvArGU3639v9cLOyOOJaxx7A0G7kn6Z2j8aP1ilNyKEV8/n3w xMKnKc1PLS9VIb1mDYvfkxpraT7nxLCPR6doUhN0MUvrGA7tIf2obaNF2Cutv8Me1OyW NQs7rMOdCHwHFjyfs+WxXmUAonjWyWDCv7ianS0hnkjAg5nw6FIAdj9QCPa2u3jVc6kA 7TNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6p6sM/wEMJMaWKqu8Fo57MKRbIIHP4AdJZkThoBGuAI=; b=CPDS2NnBf9eWXsA0O+g8zhAw9OS8GeblQFbVg3VpeWoIDivWQCEC1nGBkW6MAxMTtG Jjhau9tgmiHQKl6OGDXZVuv8zIze9Hoyggm42h9gjhlnDjS8IXCT2mswBLSLacbpW2BN lFZlFIjPJmK7Eym9Bg8REMs7BuUO1jK2jnBYOhVGMYPrjfMyk0wdtMBSDq1TLgKN4TYI d/6fjyIXJtGoRLMqqEGJqr0v4BTzuwLdeQSaXHG7naasKbPbFje/LtfBmDsYCHDTaaHP BTBZbHLRSFIz1zKucGGUhcOA+iq1cHaQhqsXBsDkW7j8Rc826kCas595/Z3Mn78RtpcD lGwg==
X-Gm-Message-State: AOAM532ObLUG21YP5bbjSn5XSHq9GpuqjiM2BgsvdwPlb5B452QFnlqj J95duPJ/xIfOEkIApSM+gli4vZon6wKtlgYGnIdLoQ==
X-Google-Smtp-Source: ABdhPJxBslmXpGTxqsf0AfeUz57vghwHRhQheFI9J0BeZldzvy1FL/NnuSodtJ/FVZnRXPCtFdw4NIvuhBqvoATBLHg=
X-Received: by 2002:a25:bd93:: with SMTP id f19mr5137054ybh.155.1601680443243; Fri, 02 Oct 2020 16:14:03 -0700 (PDT)
MIME-Version: 1.0
References: <CAMCkG5u5YjqNrQu=Uth7F=QPvAy9-BwBCoQcMXd=ihMFjcHcmw@mail.gmail.com> <33AA53B6-D6E1-498C-AC47-470ABB558BDB@mit.edu> <CAMCkG5u6dVe7qKLfXhiesUNan2VwvRUFXxppzUnpT=7HQ7W_3A@mail.gmail.com> <947809F3-7C03-478F-B3A5-A483E9426375@gmail.com>
In-Reply-To: <947809F3-7C03-478F-B3A5-A483E9426375@gmail.com>
From: Atul Tulshibagwale <atultulshi@google.com>
Date: Fri, 02 Oct 2020 16:13:52 -0700
Message-ID: <CAMCkG5t=rJKOskyRvcg5g0sV4Lf7U1zq_VTLwTHQKtbG6L=FSg@mail.gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, SecEvent <id-event@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dd52d505b0b8491f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/jgsbTE30DLJxzu6L8qFeVmIvktE>
Subject: Re: [Id-event] Draft-06 issue re: subject principal grouping
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: Fri, 02 Oct 2020 23:14:07 -0000

Hi Yaron,

I agree that SPAGs would typically need to be understood by the transmitter
and receiver. However this claim need not be present in every subject
identifier, since it may not apply in many cases. Ignoring a SPAG value may
still be OK if, say, the receiver is a single tenanted receiver and the
SPAG in the subject identifier is a tenant identifier. Also, note that
SPAGs do not necessarily only identify tenants; they may identify other
subject principal groupings such as OUs, groups, etc.

In general, specifications that use the Subject Identifiers specification
could add claims that may have additional semantics relating to the
interpretation of those claims. The Subject Identifiers specification could
leave the interpretation of the additional claims open.

I believe SPAGs is going to be a common enough use case, so it should be
included in the Subject Identifiers specification as such. But I'm OK with
defining the SPAG claim in the SSE specification, if we have a way for the
Subject Identifiers specification to allow the addition of such a claim to
any subject identifier.

Thanks,
Atul

PS: There has been some discussion in the OpenID SSE WG about multiple
event streams versus using SPAGs to identify different subject groupings
within the same stream. A good venue to discuss this is the
openid-specs-risc@openid.net mailing list, and now is a good time to bring
this up. The present work is captured in the SSE profile
<https://bitbucket.org/openid/risc/src/caep-draft-01/openid-sse-profile-2_0.txt>
draft spec (the one you referred to in your email was the RISC profile,
which could be replaced with this SSE profile spec when it's ready).


On Fri, Oct 2, 2020 at 8:26 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

> Hi Justin, Atul,
>
> I think this may be a reasonable way to extend the solution.
>
> But I have a problem with Atul’s example below: the SPAG attribute that
> he’s proposing defines a scope (a.k.a. namespace) for the subject ID. I
> don’t think the receiver can act correctly on the event *unless* it
> understands the tenant ID. So this is not a benign extension that can be
> ignored by a receiver with no consequence.
>
> The SecEvent mechanism to distinguish multiple tenants is not to embed the
> tenant’s identity in the event, rather it is to use separate event streams.
> In fact, this is enabled by the OpenID SSE document [1] which defines a
> profile of this solution: “Using path components enables supporting
> multiple issuers per host. This is required in some multi-tenant hosting
> configurations.”
>
> Thanks,
>         Yaron
>
> [1]
> https://openid.net/specs/openid-risc-profile-1_0-ID1.html#rfc.section.3.2.1
>
> From: Id-event <id-event-bounces@ietf.org> on behalf of Atul
> Tulshibagwale <atultulshi=40google.com@dmarc.ietf.org>
> Date: Thursday, October 1, 2020 at 19:02
> To: Justin Richer <jricher@mit.edu>
> Cc: SecEvent <id-event@ietf.org>
> Subject: Re: [Id-event] Draft-06 issue re: subject principal grouping
>
> Hi Justin,
> Agree with the theme of the language proposed in your email. I'd like to
> propose something similar, like:
>
> "Each subject_type may define required fields. Subject identifiers MUST
> include all fields required by the subject_type, but MAY contain other
> fields, either defined as optional fields within this Subject Identifiers
> specification or elsewhere. A receiver MUST ignore fields in a Subject
> Identifier that it does not understand."
>
> Atul
>
>
> On Wed, Sep 30, 2020 at 1:51 PM Justin Richer <mailto:jricher@mit.edu>
> wrote:
> Atul,
>
> I raised this in my review as well. I think the goal of the restriction
> was to make the subject identifier objects compact and easily processed
> without getting a bunch of arbitrary stuff strung onto them, but I think
> the MUST NOT might go too far toward that.
>
>
> I would like to see the requirement relaxed but also have guidance as to
> how and when to add additional members to the object. Maybe the
> subject_type field determines the REQUIRED fields and their semantics, but
> extensions MAY add new fields? And that a receiver MUST ignore fields they
> don’t understand?
>
>
>
>  — Justin
>
>
> On Sep 29, 2020, at 8:28 PM, Atul Tulshibagwale <mailto:atultulshi=
> 40google.com@dmarc.ietf.org> wrote:
>
> Hi Annabelle,
> After reviewing the
> https://github.com/richanna/secevent/blob/master/draft-ietf-secevent-subject-identifiers.txt
> (document dated Sep 04), there's one issue that I feel needs to be
> addressed:
>
> The sentence on line 246 ("A Subject Identifier MUST NOT contain any
> members...") has the consequence that if we need to add claims in a
> specific subject identifier type (e.g. email), then we will need to define
> new subject identifier types.
>
> As discussed earlier, I am interested in adding a "Subject Principal
> Administrative Grouping" or SPAG as a property of any subject identifier.
> This is important because the same principal may appear in different
> administrative groupings, and without the disambiguation, it will be
> impossible to figure out which SPAG the event that includes a subject
> identifier applies to.
>
> For example, if the user "mailto:a@b.com" is present in two tenants of a
> service that acts as a SSE Receiver. Say the tenant names in which this
> user occurs is "http://B.com" and "http://C.com". This can happen if
> "mailto:a@b.com" is an employee of the tenant http://B.com, but is on a
> contract for a project that is run by the tenant "http://C.com".
>
> If the event received only has the subject:
> "subject" : {
>   "subject_type" : "email",
>   "email" : "mailto:a@b.com"
> }
>
> Then it will be impossible for the receiver to determine whether the event
> applies to the tenant http://B.com or http://C.com. If on the other hand,
> an optional claim "spag_id" is added, then the subject looks like:
>
> "subject" : {
>   "subject_type" : "email",
>   "email" : "mailto:a@b.com",
>   "spag_id" : "http://B.com"
> }
>
> This disambiguates the particular grouping that the event applies to.
>
> So, I feel there are at least two ways of addressing this concern:
> 1. Include SPAGs as a concept in the Subject Identifiers spec and allow a
> "spag_id" claim in any subject identifier
> 2. Drop the requirement on line 246, and allow subject identifiers to have
> additional claims, which may be defined elsewhere.
> Thanks,
> Atul
>
> _______________________________________________
> Id-event mailing list
> mailto:Id-event@ietf.org
> https://www.ietf.org/mailman/listinfo/id-event
>
> _______________________________________________ Id-event mailing list
> Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event
>
>
>