From nobody Thu Oct 1 09:02:33 2020 Return-Path: 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 34FB53A10DC for ; Thu, 1 Oct 2020 09:02:32 -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 PBRCpupcv2js for ; Thu, 1 Oct 2020 09:02:30 -0700 (PDT) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 496303A10C2 for ; Thu, 1 Oct 2020 09:02:30 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id f70so4388965ybg.13 for ; Thu, 01 Oct 2020 09:02:30 -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=rmwat8ZHZDmHWxRH1QBzu6CYKnzH3j0q8LpdDl1JCZI=; b=craxfTMN3N3pp2JTsjJIvOZYGVNWa7VgE2/oh3fdCUcQVQDRrUKz06uCO0bgZM06/S DSjR5VkCg7HpQpET6VyrgsKTDQBV34udC/4+gAXO9XHFIyjbpOF0bUXm+tEWlqyPrdo4 CTULP0ZwnjwGkeySMKI6gdkCY9HgOhpVsSoz3zv/HBZ/EEx2ILlXZue9AaFbcas3LJr+ xVzML1jJpUR7JYW0fYoYUL/FJfH4oBaixvNoX438sgUXIIaDeMNEDBCN8oGntImJVNem uqwCdygL0OrWddCg07zrAMiaIyzXmK9AcNlW0bM1mG3rdC+z3QbA9RmZ4bkA4Y3jrgYI d9hQ== 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=rmwat8ZHZDmHWxRH1QBzu6CYKnzH3j0q8LpdDl1JCZI=; b=cyX311gvmt7WotKdtAwfHmslDZXupSUMOGE8LoA4nGGLpUV5DeuaYTctQRpSu7Cv0p ozBgY2HqZNRi9+ZCTmNtI4fzAmenS/Pn7UBpgd4420Z/hFzam/6G2SR+oKQPsrp7rHNE 1ROmBpT9uWjODJ64/OS4oKUCpwrHPbEfiUdXzepRbuxtrTRNWG7ewokqrKxuPU+gpdP7 Co7XEuduti6NFX4tiNkrfdYpI/JovEGOhw03RAoYXSj4HlD19gop5dE02iI6B1wuBi45 gez0S6Mlc1Jaw7YqMX1u+UHvFU693SZGEVFDFLwu366oZPPBJquKu3e/Cdx94/8p+NvC tLjQ== X-Gm-Message-State: AOAM532gDcELDrO0u2aqMxZHAUPGF1nTqCAAX9BjEc24LdGLQnrgE4ud 1OWyVp5CcBQfzqrvWCCtOPSKl/j9b+U9wPSgtb7Qcw== X-Google-Smtp-Source: ABdhPJyUfaPTuilC3I6mxogwN7aateI3DXcyRUtWIbH4Xny9eHAsdfiq2t55rNYwcrSWDD5QhyLAGoj1eUMALU7+vdQ= X-Received: by 2002:a25:bd93:: with SMTP id f19mr9950430ybh.155.1601568149125; Thu, 01 Oct 2020 09:02:29 -0700 (PDT) MIME-Version: 1.0 References: <33AA53B6-D6E1-498C-AC47-470ABB558BDB@mit.edu> In-Reply-To: <33AA53B6-D6E1-498C-AC47-470ABB558BDB@mit.edu> From: Atul Tulshibagwale Date: Thu, 1 Oct 2020 09:02:18 -0700 Message-ID: To: Justin Richer Cc: SecEvent Content-Type: multipart/alternative; boundary="0000000000009d943105b09e2456" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 16:02:32 -0000 --0000000000009d943105b09e2456 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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, bu= t > extensions MAY add new fields? And that a receiver MUST ignore fields the= y > don=E2=80=99t understand? > > > > =E2=80=94 Justin > > On Sep 29, 2020, at 8:28 PM, Atul Tulshibagwale < > atultulshi=3D40google.com@dmarc.ietf.org> wrote: > > Hi Annabelle, > After reviewing the draft 06 > > (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 defin= e > 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 "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 occu= rs > is "B.com" and "C.com". This can happen if "a@b.com" is an employee of > the tenant B.com, but is on a contract for a project that is run by the > tenant "C.com". > > If the event received only has the subject: > "subject" : { > "subject_type" : "email", > "email" : "a@b.com" > } > > Then it will be impossible for the receiver to determine whether the even= t > applies to the tenant B.com or C.com. If on the other hand, an optional > claim "spag_id" is added, then the subject looks like: > > "subject" : { > "subject_type" : "email", > "email" : "a@b.com", > "spag_id" : "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 > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > --0000000000009d943105b09e2456 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,
Agree with the theme of the language propos= ed in your email. I'd like to propose something similar, like:

"Each subject_type may define required fields. Subjec= t identifiers MUST include all fields required by the subject_type, but MAY= contain other fields,=C2=A0either defined as optional fields within this S= ubject Identifiers specification or elsewhere. A receiver MUST ignore field= s in a Subject Identifier that it does not understand."

=
Atul


On Wed, Sep 30, 2020 at 1:51 PM Justin = Richer <jricher@mit.edu> wrote= :
Atul,

I raised this in my re= view as well. I think the goal of the restriction was to make the subject i= dentifier objects compact and easily processed without getting a bunch of a= rbitrary stuff strung onto them, but I think the MUST NOT might go too far = toward that.


I would like to see th= e requirement relaxed but also have guidance as to how and when to add addi= tional members to the object. Maybe the subject_type field determines the R= EQUIRED fields and their semantics, but extensions MAY add new fields? And = that a receiver MUST ignore fields they don=E2=80=99t understand?=C2=A0



=C2=A0=E2=80=94 Justin<= br>

On Sep 29, 2020, at 8:28 PM, Atu= l Tulshibagwale <atultulshi=3D40google.com@dmarc.ietf.org> wro= te:

Hi Annabelle,
After reviewing the draft 06 (document dated = Sep 04), there's one issue that I feel needs=C2=A0to be addressed:

The sentence=C2=A0on line=C2=A0246 ("A Subject Id= entifier 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 Pri= ncipal Administrative Grouping" or SPAG as a property of any subject i= dentifier. This is important because the same principal may appear in diffe= rent administrative groupings, and without the disambiguation, it will be i= mpossible to figure out which SPAG the event that includes a subject identi= fier applies to.

For example, if the user "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 "B.com" and "C.c= om". This can happen if "a@b.com" is an employee of the tenant B.com, but is on a contract for a project that = is run by the tenant "C.com= ".

If the event received only has the sub= ject:
"subject" : {
=C2=A0 "subject_type" : "ema= il",
=C2=A0 "email"= ; : "a@b.com"
}

T= hen it will be impossible for the receiver to determine whether the event a= pplies to the tenant B.com o= r C.com. If on the other han= d, an optional claim "spag_id" is added, then the subject looks l= ike:

"subject" = : {
=C2=A0 "subject_type&quo= t; : "email",
=C2=A0 &q= uot;email" : "a@b.co= m",
=C2=A0 "spag_id= " : "B.com"
}

= This disambiguates the particular grouping that the event applies to.
=

So, I feel there are at least two ways of addressing th= is concern:
  1. Include SPAGs as a concept in the Subject Ide= ntifiers spec and allow a "spag_id" claim in any subject identifi= er
  2. Drop the requirement on line 246, and allow subject identifiers = to have additional claims, which may be defined elsewhere.
Th= anks,
Atul

_______________________________________________
Id-event mailing listId-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

--0000000000009d943105b09e2456-- From nobody Fri Oct 2 08:26:29 2020 Return-Path: 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 0AED53A165C for ; Fri, 2 Oct 2020 08:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, MIME_QP_LONG_LINE=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 K8tMt5nGP0Gu for ; Fri, 2 Oct 2020 08:26:26 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450: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 4A9E73A1634 for ; Fri, 2 Oct 2020 08:26:26 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id m6so2288361wrn.0 for ; Fri, 02 Oct 2020 08:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=PKIZSNxHlbR7yW5FeI0RkSuo2Oq1B76ERiHtdwwtR8I=; b=c4bIRGuex+0/n1I23iFiAdYZn1CIhX4mVVbg0yyq47RF4VasOsq5Sm/yDpV3CRwdGO 0edbxo1uM9ISDJBZx0abcmcg1f8xC48WmYjOkYFdvutAY5+kEsHDDMW40Pso54BZT5bI lVld3oi/hcPTpk0CivXWhTdi3AErO5vawgjXKHujbiIWXfe/C4Ky0DJftUqwhvV9XBdK QKQdI0kTJaZLyoMaDrcws6fuLk+aoMsC+L+uczKmX9y4HP6p6fdObibV3yoHYYKtIZxV WGSI/TYPv2UjmdueHu7n751ytYM30xbrIS3v9GFVVhzuMSZnrSXC11yyK5EaGKYv+orp jTTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=PKIZSNxHlbR7yW5FeI0RkSuo2Oq1B76ERiHtdwwtR8I=; b=iKTs3JZzKaemz+OGhA+wK1IiTVHRxv/ECELB5p3M30W33Ohsn3S8SdAMUAzuVOzUtw JSwVMRyCn6e5ByczUGMFzwFcBn3UN5cSznh8KocdvSq88CmtZROJwD0Dy7RNuKtjPHXm EZYGnQQYeNKPQOvBfWOyrjYdEpeXgXvBu4RQk0ZyzTABpsaY6vYJjpZ9IyWoKA/knDfw yvnR1qT73NG8vkoQWQUWlihxzIAuzlv/APec2icKUzfZJwOpaVXxMBt1pfFRSchhcUEY +KU4pDSJXXd32Nam90pHckBF1/VvO1hZmfuEoA5AB0Ap3L4kBwvDxEuJiGW95tCGu10O jk+g== X-Gm-Message-State: AOAM532xhXyX94HaXx3BX3tMc+3IW/sdMBKTJmXVnyuorjp/dIl8Jq31 CV6qS24Hq9RQ2KtOLK0c370= X-Google-Smtp-Source: ABdhPJz1pT8xfYJ0lXiT6DFtHW2l48EY5wRifwJg+Bv6PqMOhGA8WfP/xCtbo7FRuT3QILTKaijxzw== X-Received: by 2002:adf:dcd1:: with SMTP id x17mr3957828wrm.150.1601652384576; Fri, 02 Oct 2020 08:26:24 -0700 (PDT) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id a3sm2103597wmb.46.2020.10.02.08.26.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2020 08:26:23 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.41.20091302 Date: Fri, 02 Oct 2020 18:26:22 +0300 From: Yaron Sheffer To: Atul Tulshibagwale , Justin Richer CC: SecEvent Message-ID: <947809F3-7C03-478F-B3A5-A483E9426375@gmail.com> Thread-Topic: [Id-event] Draft-06 issue re: subject principal grouping References: <33AA53B6-D6E1-498C-AC47-470ABB558BDB@mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 15:26:28 -0000 Hi Justin, Atul, I think this may be a reasonable way to extend the solution. But I have a problem with Atul=E2=80=99s example below: the SPAG attribute that h= e=E2=80=99s proposing defines a scope (a.k.a. namespace) for the subject ID. I don= =E2=80=99t think the receiver can act correctly on the event *unless* it understan= ds 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=E2=80=99s 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 pr= ofile of this solution: =E2=80=9CUsing path components enables supporting multiple= issuers per host. This is required in some multi-tenant hosting configurati= ons.=E2=80=9D Thanks, Yaron [1] https://openid.net/specs/openid-risc-profile-1_0-ID1.html#rfc.section.3= .2.1 From: Id-event on behalf of Atul Tulshibagwale = Date: Thursday, October 1, 2020 at 19:02 To: Justin Richer Cc: SecEvent 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 pr= opose something similar, like: "Each subject_type may define required fields. Subject identifiers MUST inc= lude all fields required by the subject_type, but MAY contain other fields,=C2= =A0either defined as optional fields within this Subject Identifiers specifica= tion or elsewhere. A receiver MUST ignore fields in a Subject Identifier tha= t it does not understand." Atul On Wed, Sep 30, 2020 at 1:51 PM Justin Richer wrot= e: 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 N= OT might go too far toward that. I would like to see the requirement relaxed but also have guidance as to ho= w and when to add additional members to the object. Maybe the subject_type f= ield determines the REQUIRED fields and their semantics, but extensions MAY = add new fields? And that a receiver MUST ignore fields they don=E2=80=99t understa= nd?=C2=A0 =C2=A0=E2=80=94 Justin On Sep 29, 2020, at 8:28 PM, Atul Tulshibagwale 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 i= ssue that I feel needs=C2=A0to be addressed: The sentence=C2=A0on line=C2=A0246 ("A Subject Identifier MUST NOT contain any memb= ers...") has the consequence that if we need to add claims in a specific sub= ject identifier type (e.g. email), then we will need to define new subject i= dentifier types. As discussed earlier, I am interested in adding a "Subject Principal Admini= strative 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 o= ut 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 se= rvice that acts as a SSE Receiver. Say the tenant names in which this user o= ccurs is "http://B.com" and "http://C.com". This can happen if "mailto:a@b.c= om" is an employee of the tenant http://B.com, but is on a contract for a pr= oject that is run by the tenant "http://C.com". If the event received only has the subject: "subject" : { =C2=A0 "subject_type" : "email", =C2=A0 "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" : { =C2=A0 "subject_type" : "email", =C2=A0 "email" : "mailto:a@b.com", =C2=A0 "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-ev= ent@ietf.org https://www.ietf.org/mailman/listinfo/id-event=20 From nobody Fri Oct 2 16:14:08 2020 Return-Path: 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 ; 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 ; 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 ; Fri, 2 Oct 2020 16:14:04 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id x8so2284691ybe.12 for ; 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: <33AA53B6-D6E1-498C-AC47-470ABB558BDB@mit.edu> <947809F3-7C03-478F-B3A5-A483E9426375@gmail.com> In-Reply-To: <947809F3-7C03-478F-B3A5-A483E9426375@gmail.com> From: Atul Tulshibagwale Date: Fri, 2 Oct 2020 16:13:52 -0700 Message-ID: To: Yaron Sheffer Cc: Justin Richer , SecEvent Content-Type: multipart/alternative; boundary="000000000000dd52d505b0b8491f" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 23:14:07 -0000 --000000000000dd52d505b0b8491f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 wrote: > Hi Justin, Atul, > > I think this may be a reasonable way to extend the solution. > > But I have a problem with Atul=E2=80=99s example below: the SPAG attribut= e that > he=E2=80=99s proposing defines a scope (a.k.a. namespace) for the subject= ID. I > don=E2=80=99t 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 th= e > tenant=E2=80=99s identity in the event, rather it is to use separate even= t streams. > In fact, this is enabled by the OpenID SSE document [1] which defines a > profile of this solution: =E2=80=9CUsing path components enables supporti= ng > multiple issuers per host. This is required in some multi-tenant hosting > configurations.=E2=80=9D > > Thanks, > Yaron > > [1] > https://openid.net/specs/openid-risc-profile-1_0-ID1.html#rfc.section.3.2= .1 > > From: Id-event on behalf of Atul > Tulshibagwale > Date: Thursday, October 1, 2020 at 19:02 > To: Justin Richer > Cc: SecEvent > 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 > 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, bu= t > extensions MAY add new fields? And that a receiver MUST ignore fields the= y > don=E2=80=99t understand? > > > > =E2=80=94 Justin > > > On Sep 29, 2020, at 8:28 PM, Atul Tulshibagwale 40google.com@dmarc.ietf.org> wrote: > > Hi Annabelle, > After reviewing the > https://github.com/richanna/secevent/blob/master/draft-ietf-secevent-subj= ect-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 defin= e > 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 even= t > 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 hav= e > 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 > > > --000000000000dd52d505b0b8491f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Yaron,

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

In general, specificati= ons that use the Subject Identifiers specification could add claims that ma= y have additional semantics relating to the interpretation of those claims.= The Subject Identifiers specification could leave the interpretation of th= e additional claims open.

I believe SPAGs is going= to be a common enough use case, so it should be included in the Subject Id= entifiers specification as such. But I'm OK with defining the SPAG clai= m in the SSE specification, if we have a way for the Subject Identifiers sp= ecification 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 even= t 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 draft = spec (the one you referred to in your email was the RISC profile, which cou= ld 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> wr= ote:
Hi Justin, = Atul,

I think this may be a reasonable way to extend the solution.

But I have a problem with Atul=E2=80=99s example below: the SPAG attribute = that he=E2=80=99s proposing defines a scope (a.k.a. namespace) for the subj= ect ID. I don=E2=80=99t think the receiver can act correctly on the event *= unless* it understands the tenant ID. So this is not a benign extension tha= t can be ignored by a receiver with no consequence.

The SecEvent mechanism to distinguish multiple tenants is not to embed the = tenant=E2=80=99s identity in the event, rather it is to use separate event = streams. In fact, this is enabled by the OpenID SSE document [1] which defi= nes a profile of this solution: =E2=80=9CUsing path components enables supp= orting multiple issuers per host. This is required in some multi-tenant hos= ting configurations.=E2=80=9D

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

[1] https://openid.net/sp= ecs/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 &l= t;atultulshi=3D40google.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 t= o propose something similar, like:

"Each subject_type may define required fields. Subject identifiers MUS= T include all fields required by the subject_type, but MAY contain other fi= elds,=C2=A0either defined as optional fields within this Subject Identifier= s specification or elsewhere. A receiver MUST ignore fields in a Subject Id= entifier 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 withou= t 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 ho= w and when to add additional members to the object. Maybe the subject_type = field determines the REQUIRED fields and their semantics, but extensions MA= Y add new fields? And that a receiver MUST ignore fields they don=E2=80=99t= understand?=C2=A0



=C2=A0=E2=80=94 Justin


On Sep 29, 2020, at 8:28 PM, Atul Tulshibagwale <mailto:atultulshi=3D40google.com@dmarc.ietf.org> = wrote:

Hi Annabelle,
After reviewing the https://github.com/richanna/secevent/blob/master/draft-ietf-sec= event-subject-identifiers.txt (document dated Sep 04), there's one = issue that I feel needs=C2=A0to be addressed:

The sentence=C2=A0on line=C2=A0246 ("A Subject Identifier MUST NOT con= tain any members...") has the consequence that if we need to add claim= s 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 A= dministrative Grouping" or SPAG as a property of any subject identifie= r. This is important because the same principal may appear in different adm= inistrative groupings, and without the disambiguation, it will be impossibl= e to figure out which SPAG the event that includes a subject identifier app= lies 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<= /a>" and "http://C.com". This can happen if "mailto:a@b.com" is an employee of the te= nant http://B= .com, but is on a contract for a project that is run by the tenant &quo= t;http://C.co= m".

If the event received only has the subject:
"subject" : {
=C2=A0 "subject_type" : "email",
=C2=A0 "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 &= quot;spag_id" is added, then the subject looks like:

"subject" : {
=C2=A0 "subject_type" : "email",
=C2=A0 "email" : "mailto:a@b.com",
=C2=A0 "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 &= quot;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


--000000000000dd52d505b0b8491f-- From nobody Tue Oct 13 11:44:29 2020 Return-Path: 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 C94D83A0FC3 for ; Tue, 13 Oct 2020 11:44:27 -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 39u_BICs4TO6 for ; Tue, 13 Oct 2020 11:44:25 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 8DFC43A0FC8 for ; Tue, 13 Oct 2020 11:44:24 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id x20so488838ybs.8 for ; Tue, 13 Oct 2020 11:44:24 -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=LGp4ag5RSrI5nizSfSvqk19X8IOWMElHPO+i01h6jnQ=; b=hxB/0mCI75qmlrpkmkm0VlLq3jIfVnTkFMudH5BanD4QH4zV7MUEIursgoU0tiPcPs lf+gvse7N/FPUlUuBgMNMq5Te47lBtIo5obbyIY9DMUqE3/gzKgsWzb+nbVhDgtqf4Xi w9/CD2RxMAkIFXx4NtfyM4Zx0z1cPOBOj7ubyS7ZLO4W6CkmiMDRRwu7eIsKMmz3wHg4 epG9lmu8vnXJ/mVwtTFXwM/6oO0EeOhSawvf/qKkzjQi8IfSksWSnd92UzxKKaD3pOVI kFLfD5gys5+RYwQkgusGUAV2rnbuSiXlZcsS4y4iy2ngd+74RQs/U9Ou7y0SOa6r22Yb Za6g== 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=LGp4ag5RSrI5nizSfSvqk19X8IOWMElHPO+i01h6jnQ=; b=MNsrUCWaFhMeMNzZ0SPfMvsyia3a/EUUn60BKQ261q0ZEpFVGlwExGb5hAwdP7OX0q WSha6aJXXASDTHU0hIdkxPBckwI+aq4yLaUDu8G8DtaAeA52yVw+PVSX6CueGmXkXuh+ FQyKeLE+K9TNtjU+s618xc26LBzOKF2KoM6nq4VtyIXCdRozTNZ53rWdhAPVH7XqXb2L xFUn9+8aNjWFEO4EWluuq5Uj2NthTuPI9Ha1X7aWt4c8pXD8+7XZA6OjfPy1hu3X5NFy zfrfWLuNyy4wL1lho8WdI6VjFcWVzRu1U0+Gs3xzn6mS1J3645kxGdXzEUtUCxNFAYHT il5A== X-Gm-Message-State: AOAM531isc3nUc/PyIkwvhDerseBIRfYXN1zqgmL+lkvFL/u590NRcpW Re0v4CPHKgNpM7zQhhw92wDT0VSUvLrWVO9JJwbEvg== X-Google-Smtp-Source: ABdhPJyFgR/Y9cJQud3yg3+LEKJ/QyzgyG8iq8Jy5kw/4ANF1VouMKIBe1Jmfb70cOQSnQRzQBlaZcQaWuHeyBeHFFo= X-Received: by 2002:a25:f84:: with SMTP id 126mr1594804ybp.377.1602614663338; Tue, 13 Oct 2020 11:44:23 -0700 (PDT) MIME-Version: 1.0 References: <33AA53B6-D6E1-498C-AC47-470ABB558BDB@mit.edu> <947809F3-7C03-478F-B3A5-A483E9426375@gmail.com> In-Reply-To: From: Atul Tulshibagwale Date: Tue, 13 Oct 2020 11:44:12 -0700 Message-ID: To: Yaron Sheffer Cc: Justin Richer , SecEvent Content-Type: multipart/alternative; boundary="000000000000b8f2df05b191cd4b" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 18:44:28 -0000 --000000000000b8f2df05b191cd4b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 cou= ld > 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 wit= h > defining the SPAG claim in the SSE specification, if we have a way for th= e > Subject Identifiers specification to allow the addition of such a claim t= o > 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 > > 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 > wrote: > >> Hi Justin, Atul, >> >> I think this may be a reasonable way to extend the solution. >> >> But I have a problem with Atul=E2=80=99s example below: the SPAG attribu= te that >> he=E2=80=99s proposing defines a scope (a.k.a. namespace) for the subjec= t ID. I >> don=E2=80=99t 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=E2=80=99s 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: =E2=80=9CUsing path components enabl= es >> supporting multiple issuers per host. This is required in some multi-ten= ant >> hosting configurations.=E2=80=9D >> >> Thanks, >> Yaron >> >> [1] >> https://openid.net/specs/openid-risc-profile-1_0-ID1.html#rfc.section.3.= 2.1 >> >> From: Id-event on behalf of Atul >> Tulshibagwale >> Date: Thursday, October 1, 2020 at 19:02 >> To: Justin Richer >> Cc: SecEvent >> 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 Identifier= s >> 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 >> 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, b= ut >> extensions MAY add new fields? And that a receiver MUST ignore fields th= ey >> don=E2=80=99t understand? >> >> >> >> =E2=80=94 Justin >> >> >> On Sep 29, 2020, at 8:28 PM, Atul Tulshibagwale > 40google.com@dmarc.ietf.org> wrote: >> >> Hi Annabelle, >> After reviewing the >> https://github.com/richanna/secevent/blob/master/draft-ietf-secevent-sub= ject-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 defi= ne >> 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 >> >> >> --000000000000b8f2df05b191cd4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Annabelle,

Could you please provide an update= on whether this change (any of the two proposed options) is possible in th= is Subject Identifiers specification? The work in the OpenID SSE WG cannot = proceed without this clarification.

Thanks,
<= div>Atul

On Fri, Oct 2, 2020 at 4:13 PM Atul Tulshibagwale <<= a href=3D"mailto:atultulshi@google.com">atultulshi@google.com> wrote= :
Hi=C2=A0Yaron,

I agree that SPAGs would typically nee= d 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= =C2=A0cases. 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 ten= ant identifier. Also,=C2=A0note 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 t= he Subject Identifiers specification could add claims that may have additio= nal semantics relating to the interpretation of those claims. The Subject I= dentifiers specification could leave the interpretation of the additional c= laims open.

I believe SPAGs is going to be a commo= n enough use case, so it should be included in the Subject Identifiers spec= ification as such. But I'm OK with defining the SPAG claim in the SSE s= pecification, 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 vers= us using SPAGs to identify different subject groupings within the same stre= am. A good venue to discuss this is the openid-specs-risc@openid.net mailing lis= t, and now is a good time to bring this up. The present work is captured in= the SSE profile 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 F= ri, 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=E2=80=99s example below: the SPAG attribute = that he=E2=80=99s proposing defines a scope (a.k.a. namespace) for the subj= ect ID. I don=E2=80=99t think the receiver can act correctly on the event *= unless* it understands the tenant ID. So this is not a benign extension tha= t can be ignored by a receiver with no consequence.

The SecEvent mechanism to distinguish multiple tenants is not to embed the = tenant=E2=80=99s identity in the event, rather it is to use separate event = streams. In fact, this is enabled by the OpenID SSE document [1] which defi= nes a profile of this solution: =E2=80=9CUsing path components enables supp= orting multiple issuers per host. This is required in some multi-tenant hos= ting configurations.=E2=80=9D

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

[1] https://openid.net/sp= ecs/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 &l= t;atultulshi=3D40google.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 t= o propose something similar, like:

"Each subject_type may define required fields. Subject identifiers MUS= T include all fields required by the subject_type, but MAY contain other fi= elds,=C2=A0either defined as optional fields within this Subject Identifier= s specification or elsewhere. A receiver MUST ignore fields in a Subject Id= entifier 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 withou= t 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 ho= w and when to add additional members to the object. Maybe the subject_type = field determines the REQUIRED fields and their semantics, but extensions MA= Y add new fields? And that a receiver MUST ignore fields they don=E2=80=99t= understand?=C2=A0



=C2=A0=E2=80=94 Justin


On Sep 29, 2020, at 8:28 PM, Atul Tulshibagwale <mailto:atultulshi=3D40google.com@dmarc.ietf.org> = wrote:

Hi Annabelle,
After reviewing the https://github.com/richanna/secevent/blob/master/draft-ietf-sec= event-subject-identifiers.txt (document dated Sep 04), there's one = issue that I feel needs=C2=A0to be addressed:

The sentence=C2=A0on line=C2=A0246 ("A Subject Identifier MUST NOT con= tain any members...") has the consequence that if we need to add claim= s 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 A= dministrative Grouping" or SPAG as a property of any subject identifie= r. This is important because the same principal may appear in different adm= inistrative groupings, and without the disambiguation, it will be impossibl= e to figure out which SPAG the event that includes a subject identifier app= lies 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<= /a>" and "http://C.com". This can happen if "mailto:a@b.com" is an employee of the te= nant http://B= .com, but is on a contract for a project that is run by the tenant &quo= t;http://C.co= m".

If the event received only has the subject:
"subject" : {
=C2=A0 "subject_type" : "email",
=C2=A0 "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 &= quot;spag_id" is added, then the subject looks like:

"subject" : {
=C2=A0 "subject_type" : "email",
=C2=A0 "email" : "mailto:a@b.com",
=C2=A0 "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 &= quot;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


--000000000000b8f2df05b191cd4b--