Re: [Id-event] Draft-06 issue re: subject principal grouping
Dick Hardt <dick.hardt@gmail.com> Wed, 02 December 2020 19:58 UTC
Return-Path: <dick.hardt@gmail.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 C83613A1543 for <id-event@ietfa.amsl.com>; Wed, 2 Dec 2020 11:58:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 SVLjy4RH_qLF for <id-event@ietfa.amsl.com>; Wed, 2 Dec 2020 11:58:09 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 C5F5A3A1541 for <id-event@ietf.org>; Wed, 2 Dec 2020 11:58:08 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id l11so6729361lfg.0 for <id-event@ietf.org>; Wed, 02 Dec 2020 11:58:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M5y0MQ68Vx+mwgoeADtX1PX94eiaVb3wQSkTQogUDc0=; b=f55n0U7ZLhEr9m1tjiCJQH2n5ewBStEBYfx4Ncu2w+kTSS3YBDx0XKOJeKdco34yjL 0pCrJCGxkC1W+3owStC3UMevCD+FYbEbBy/fBBJy3GkU+X3a0IHBudMIrDThiepNW081 A1dRWkzX0YeNhgA47Lfmn/2Ugv66MZTlspsuoou5Ey2NZaYiEJcX1OB38dTUxXl0W7FH ZACEXNISp+VCZ6uH6RR8cwTxEyQ8FFRUgULXfppni+yUjV0sWHKc1ekawwn6LX4D8wVR e9WwRJFEE/I3GYKwGaj7sIYHjAXDtkZSnGpvgPERXYn3vWC/Da1cluKpg/Ly/irrn86M iNng==
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=M5y0MQ68Vx+mwgoeADtX1PX94eiaVb3wQSkTQogUDc0=; b=KBJgVPu60nKNi66Uzbeah9bLl8sF8LDiUSf6+4/M7VW2FIvfCZ4AhSYbtRS0MJAMOU QaJUB1QbuA9qYVuPtfmbknkb1/Sf0+1+w1LxelPOxOy4Xuv8jbk3FyNJKsu9pDPXM0YP CzuiOoAByeyP8ck75tzmadQdC+gzhtLuDVs0h0l76lr9BHh3HgAIqz61j+QIgObzgUhs HHhd199BHwbiFNV7WkhmU51EY5/evqdE53f+UkSc6MMU6wN5XgyWMsZH5Fl/AFzU3dBD 3Ni0gSV6AeUMc00gI0JpFAdkMJr+jUlbdLKwgPZUL0XiLQqcoZRVkUVlnxvtLefOf7DT 2TtQ==
X-Gm-Message-State: AOAM533Iq3ntdC/KiYtUo9d0nS59bzFDXzvFnLADVRuj/p9/wHD5Sb34 XjIW1mkJrDl3V4IG8vVAng+AhJ8JxmRyWxfg0Fg=
X-Google-Smtp-Source: ABdhPJzo4IuYxpu1pauw9VQ2kLj9OZrMrJVhihBZd1unZ85t58jLw5Hqlk781mYI8mKsAGSEUzrd/k4NOV9UYZXbNPA=
X-Received: by 2002:a19:6e4c:: with SMTP id q12mr1865598lfk.162.1606939085210; Wed, 02 Dec 2020 11:58:05 -0800 (PST)
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> <CAMCkG5t=rJKOskyRvcg5g0sV4Lf7U1zq_VTLwTHQKtbG6L=FSg@mail.gmail.com> <CAMCkG5u2sVALP38cAhDnvfXsORSxPe-LeZ0ignsUQBzwgr1U-Q@mail.gmail.com> <CAMCkG5v251jTkQqpXUzRsq68ZQZ3YzUo1zwYUeDbn0hTypqLOA@mail.gmail.com>
In-Reply-To: <CAMCkG5v251jTkQqpXUzRsq68ZQZ3YzUo1zwYUeDbn0hTypqLOA@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Wed, 02 Dec 2020 11:57:29 -0800
Message-ID: <CAD9ie-vv=3G_3hEbvpUB4b8-csCkcP-0KzUay6vL6gZE=isj5A@mail.gmail.com>
To: Atul Tulshibagwale <atultulshi=40google.com@dmarc.ietf.org>, SecEvent <id-event@ietf.org>, "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000598d0505b580a9a9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/VF12EJ7MAJrxXMoEaMmAlVqhqVg>
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: Wed, 02 Dec 2020 19:58:12 -0000
Annabelle / Atul Has the SPAG issue been resolved? Would be great to get resolution and consensus so we can propose a last call again for this draft. /Dick ᐧ On Wed, Nov 25, 2020 at 9:05 AM Atul Tulshibagwale <atultulshi= 40google.com@dmarc.ietf.org> wrote: > Pinging this topic as discussed in the CAEP call yesterday. > > On Tue, Oct 13, 2020 at 11:44 AM Atul Tulshibagwale <atultulshi@google.com> > wrote: > >> Annabelle, >> >> Could you please provide an update on whether this change (any of the two >> proposed options) is possible in this Subject Identifiers specification? >> The work in the OpenID SSE WG cannot proceed without this clarification. >> >> Thanks, >> Atul >> >> On Fri, Oct 2, 2020 at 4:13 PM Atul Tulshibagwale <atultulshi@google.com> >> wrote: >> >>> 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 >>>> >>>> >>>> _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >
- [Id-event] Draft-06 issue re: subject principal g… Atul Tulshibagwale
- Re: [Id-event] Draft-06 issue re: subject princip… Justin Richer
- Re: [Id-event] Draft-06 issue re: subject princip… Atul Tulshibagwale
- Re: [Id-event] Draft-06 issue re: subject princip… Yaron Sheffer
- Re: [Id-event] Draft-06 issue re: subject princip… Atul Tulshibagwale
- Re: [Id-event] Draft-06 issue re: subject princip… Atul Tulshibagwale
- Re: [Id-event] Draft-06 issue re: subject princip… Atul Tulshibagwale
- Re: [Id-event] Draft-06 issue re: subject princip… Dick Hardt
- Re: [Id-event] Draft-06 issue re: subject princip… Atul Tulshibagwale
- Re: [Id-event] Draft-06 issue re: subject princip… Dick Hardt