Re: [Id-event] Consensus :: Single Event Syntax
Justin Richer <jricher@mit.edu> Mon, 18 December 2017 14:35 UTC
Return-Path: <jricher@mit.edu>
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 8D68F12D7E8 for <id-event@ietfa.amsl.com>; Mon, 18 Dec 2017 06:35:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.598
X-Spam-Level:
X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.712, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 07HgzE0BO4Gx for <id-event@ietfa.amsl.com>; Mon, 18 Dec 2017 06:34:55 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B2812D7E4 for <id-event@ietf.org>; Mon, 18 Dec 2017 06:34:53 -0800 (PST)
X-AuditID: 12074423-5a1ff70000006d1f-a6-5a37d207d41c
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id B1.FC.27935.802D73A5; Mon, 18 Dec 2017 09:34:51 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id vBIEYdB2028869; Mon, 18 Dec 2017 09:34:41 -0500
Received: from [192.168.1.3] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vBIEYaUj031095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Dec 2017 09:34:37 -0500
To: Mike Jones <Michael.Jones@microsoft.com>, Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, Phil Hunt <phil.hunt@oracle.com>, Benjamin Kaduk <bkaduk@akamai.com>, "id-event@ietf.org" <id-event@ietf.org>
References: <CAD9ie-s_tmCqwBh0u=89Zx7FZEUMq0-TcPY_t-3t006oTrTbmw@mail.gmail.com> <208F3BBC-0308-4CE7-94A4-2549FB607214@oracle.com> <4087B4FF-56EE-4F7C-B179-8007C7B2DFA4@amazon.com> <5752AC55-749B-4B4E-905B-43D17D108489@oracle.com> <4A743ECC-5216-4F8D-8AF4-25651834E501@oracle.com> <19C1D4B7-0424-49E4-8305-3CE4F67E60FC@amazon.com> <CY4PR21MB05048F05E120234F0B0B4AFBF50A0@CY4PR21MB0504.namprd21.prod.outlook.com> <16D31AAA-1A4E-4335-8452-E49B1294585D@amazon.com> <22173DA2-CC6C-4619-88A5-81A02AFB0FE6@oracle.com> <2891DA91-67B6-4467-8D5D-BFEAA836012D@amazon.com> <CAGdjJp+HS+v0_=ncP=qzf9i3jdJQu4RoME4kV5Z9jjX0g3ZKpQ@mail.gmail.com> <9CFDB49B-9311-4C66-99FC-D56189CB63E3@mit.edu> <CY4PR21MB0504969FB9E00D2A003F1725F50B0@CY4PR21MB0504.namprd21.prod.outlook.com> <CAGdjJpJ_CvSuJqs6TQUpQhXCf+2_E3y+n49MNqUACWQ4GyFJWg@mail.gmail.com> <A29C6CF0-76AB-4523-A066-429296E7E187@mit.edu> <CY4PR21MB05047F0AD72E9144DB214F4EF5090@CY4PR21MB0504.namprd21.prod.outlook.com>
From: Justin Richer <jricher@mit.edu>
Message-ID: <6b77369c-2d69-32d1-cbb4-4263d9132efa@mit.edu>
Date: Mon, 18 Dec 2017 09:34:30 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <CY4PR21MB05047F0AD72E9144DB214F4EF5090@CY4PR21MB0504.namprd21.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------29CF55FFC6EB2EBBED5E80C2"
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPKsWRmVeSWpSXmKPExsUixG6nost9yTzK4O11U4vGzY2sFh0Lupks 9k77xGJx6+waJosF8xvZLdofcziweUw+soDZY8WFLlaPBZtKPZYs+cnk0brjL7vHx6e3WALY orhsUlJzMstSi/TtErgyzn37zFgwqUWl4tLlq0wNjMvO8XQxcnJICJhItHX9Y+1i5OIQEljM JPHsaScbhLORUaLx1mkmCOcak0Tv1nWsIC3CAhYSqydOAkpwcIgIxEsc+G4LEmYW2M4ocWxl GkT9TXaJH9u72EESbAKqEtPXtIDV8wpYSfw/YwQSZgEKL760F2ykqECMxOGe6WA2r4CgxMmZ T1hAbE6BWImPs/qYIOaHSaw7/oEFwhaXuPVkPtMERoFZSFpmISmbhaQMwjaTmLf5ITOELS/R vHU2kM0BZKtJLGtVQhZewMi+ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdMLzezRC81pXQTIziu XJR3ML7s8z7EKMDBqMTDe+KyWZQQa2JZcWXuIUZJDiYlUd6Z3EAhvqT8lMqMxOKM+KLSnNTi Q4wSHMxKIrx+Z82jhHhTEiurUovyYVLSHCxK4rweJtpRQgLpiSWp2ampBalFMFkZDg4lCV7m i0CNgkWp6akVaZk5JQhpJg5OkOE8QMNTLoAMLy5IzC3OTIfIn2LU5Xg283UDsxBLXn5eqpQ4 70OQIgGQoozSPLg5oHTovs7O4hWjONBbwrylIOt4gKkUbtIroCVMQEumRoAtKUlESEk1MAY2 Glb3y3qJbji+crP2Lz8eJuMpzJm1KyInz097/zHsbne8/rHIPQsvs74JVT7w5l+V1TT3tG1G SbEas5f4WmbdPHHoU17wZveKmR/+Furukj+yhrftzh1N7YiCtc62z2btqNF/E/Aw2sf882+f +ZW+aesTl86afF/iNudd7opzFdUTL1mZiCmxFGckGmoxFxUnAgDZhyZxYgMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/fOky7efjdzyCW0YofPH8fOb10XM>
Subject: Re: [Id-event] Consensus :: Single Event Syntax
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 18 Dec 2017 14:35:03 -0000
I disagree, Mike. My stance takes into account those that say the current structure works for them, and trying to understand how the new structure would work as well. Instead, I believe you're miscategorizing the support. Consent Receipts is not using SET right now, and doing so at all would mean a syntax change for them no matter which format was used. I had advocated that the group follow this work when I brought the use case over here initially, but they've been developing in their own space instead. The 1.1 draft version of CR could be easily carried in either format, with some tweaks. The SCIM working group does not exist and, as raised in Seoul, there's a question where any SCIM based work would go. So that's not real, and could go either way. As you mentioned, the RISC group is split on the issue. You're counting all of these as support for the old format where you could easily count them as support for the new format -- since "it works for me" applies both ways. -- Justin On 12/17/2017 5:12 PM, Mike Jones wrote: > > Justin, I believe that you are severely mischaracterizing the reality > on the ground. Developers building at least four use cases have > stated that the existing specification works well for their use case: > > * SCIM > * Back-Channel Logout > * Consent Receipts > * RISC > > Yes, I understand that some RISC developers have also advocated > changing the data structure, but doing so would mean ignoring the > feedback from the early (and not-so early) developers of all the other > use cases, and also ignoring the RISC members who think that we’re > already good to go. > > -- Mike > > *From:* Justin Richer [mailto:jricher@mit.edu] > *Sent:* Sunday, December 17, 2017 11:41 AM > *To:* Marius Scurtescu <mscurtescu@google.com> > *Cc:* Mike Jones <Michael.Jones@microsoft.com>; Richard Backman, > Annabelle <richanna@amazon.com>; Phil Hunt <phil.hunt@oracle.com>; > Benjamin Kaduk <bkaduk@akamai.com>; id-event@ietf.org > *Subject:* Re: [Id-event] Consensus :: Single Event Syntax > > I honestly do not find the current syntax simpler — and I proposed it. > Annabelle did a better job at expressing and enabling what I was > after. I found the parallel arrays of early drafts to be absurdly > complex , and tried to simplify from that point into something > somewhat reasonable. I had no intention, or inkling, that it would be > abused in the way that people are currently talking about. And if the > syntax is so easily abused, in all the ways that have been described > on this list (such as multiple ambiguous objects, confusion about > primary/secondary, extension vs. parallelism, batch payloads, etc, > etc, etc), then we need to ask ourselves if the syntax is in fact any > good or if it’s a bad design. I now believe it’s a bad design, and > we’ve got a chance to fix it based on feedback from early implementers. > > I fully appreciate that people don’t like to change things, but I’m > afraid that if we don’t change things now when they’re under our > control, we’re going to be stuck in the very short future with a > competing standard that muddies the water — or worse, a set of > mutually incompatible or incomprehensible things that all “comply” > with a meaningless spec. > > I said in Seoul that we need to focus on commonality. This latest > discussion has been a strong call for codifying that commonality, with > a small chorus of “it works for my slice and I don’t care about > anything else” that doesn’t want to discuss anything anymore. You have > to realize, this isn’t people saying “hang on we just need to think > harder about this”, without bringing concrete arguments and use cases > to the table. I’ve seen that stall tactic applied in the IETF > countless times, and if that were being applied here you can be sure > I’d call it out. We sent the draft for last call. We got feedback. We > ignore this at our own peril. > > — Justin > > On Dec 15, 2017, at 11:50 AM, Marius Scurtescu > <mscurtescu@google.com <mailto:mscurtescu@google.com>> wrote: > > Simpler? Yes. > > Working? For some use cases, yes. > > Mike, it would be useful if you actually spelled out the reasons > why we should hold on to it. Two minor reasons are above, what are > the great ones? > > Also, if you disagree with the reasons presented for the new > syntax, it would be constructive to hear why. > > > Marius > > On Fri, Dec 15, 2017 at 8:12 AM, Mike Jones > <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> > wrote: > > The current syntax is demonstrably working and substantially > simpler than the proposed alternative. Those are great > reasons to hold onto it. > > *From:* Justin Richer [mailto:jricher@mit.edu > <mailto:jricher@mit.edu>] > *Sent:* Friday, December 15, 2017 7:09 AM > *To:* Marius Scurtescu <mscurtescu@google.com > <mailto:mscurtescu@google.com>> > *Cc:* Richard Backman, Annabelle <richanna@amazon.com > <mailto:richanna@amazon.com>>; Phil Hunt <phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com>>; Mike Jones > <Michael.Jones@microsoft.com > <mailto:Michael.Jones@microsoft.com>>; Benjamin Kaduk > <bkaduk@akamai.com <mailto:bkaduk@akamai.com>>; > id-event@ietf.org <mailto:id-event@ietf.org> > *Subject:* Re: [Id-event] Consensus :: Single Event Syntax > > +1 to Annabelle and Marius. The current syntax is demonstrably > broken for the purposes that people are claiming it’s needed > for. Why are we hanging on to it? > > On Dec 14, 2017, at 6:22 PM, Marius Scurtescu > <mscurtescu@google.com <mailto:mscurtescu@google.com>> wrote: > > On Thu, Dec 14, 2017 at 3:03 PM, Richard Backman, > Annabelle<richanna@amazon.com > <mailto:richanna@amazon.com>>wrote: > > You can’t conceive of any combination of event > statements that could be ambiguous? > > Here’s one possible example: > > { > > // ...other SET claims... > > "events": { > > "account_updated": { }, > > "shipping_address_added": { /* ... */ }, > > "billing_address_added": { /* ... */ }, > > "address_verified": { "is_verified": true } > > } > > } > > Does the “address_verified” event statement apply to > the shipping address or the billing address? Or both? > How would the transmitter indicate that one is > verified but the other isn’t? > > The current draft’s syntax allows for implementers to > fall into traps like this. Leaving this as a problem > for profiling specifications to solve means giving up > on general interoperability between SET profiles. > > +1 > > To add to that, we can go back to the original reasons why > multiple events are needed. At IIW we looked at this and > we came up with: > > - extensions > > - aliases > > - convenience packaging of related events > > The current format does not provide any means to convey > the above. That is ambiguity. > > Phil, you are well aware of this, you acknowledged this at > the IIW meetings. You could argue that the ambiguity is > not important in your opinion, but saying that you do not > see any ambiguity is very surprising. > > -- > > Annabelle Richard Backman > > Amazon – Identity Services > > *From:*Phil Hunt <phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com>> > *Date:*Thursday, December 14, 2017 at 1:14 PM > *To:*"Richard Backman, Annabelle" <richanna@amazon.com > <mailto:richanna@amazon.com>> > *Cc:*Mike Jones <Michael.Jones@microsoft.com > <mailto:Michael.Jones@microsoft.com>>, Benjamin Kaduk > <bkaduk@akamai.com <mailto:bkaduk@akamai.com>>, > "id-event@ietf.org <mailto:id-event@ietf.org>" > <id-event@ietf.org <mailto:id-event@ietf.org>>, Justin > Richer <jricher@mit.edu <mailto:jricher@mit.edu>> > *Subject:*Re: [Id-event] Consensus :: Single Event Syntax > > I don't see any ambiguity. > > Phil > > > On Dec 14, 2017, at 12:37 PM, Richard Backman, > Annabelle <richanna@amazon.com > <mailto:richanna@amazon.com>> wrote: > > RFC 7519 is very clear about the semantics of the > claims that it defines. Where do you see a degree > of ambiguity similar to what exists for the > “events” claim in the current draft? > > -- > > Annabelle Richard Backman > > Amazon – Identity Services > > *From:*Id-event <id-event-bounces@ietf.org > <mailto:id-event-bounces@ietf.org>> on behalf of > Mike Jones <Michael.Jones@microsoft.com > <mailto:Michael.Jones@microsoft.com>> > *Date:*Thursday, December 14, 2017 at 11:04 AM > *To:*Phil Hunt <phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com>>, "Richard Backman, > Annabelle" <richanna@amazon.com > <mailto:richanna@amazon.com>> > *Cc:*Benjamin Kaduk <bkaduk@akamai.com > <mailto:bkaduk@akamai.com>>, "id-event@ietf.org > <mailto:id-event@ietf.org>" <id-event@ietf.org > <mailto:id-event@ietf.org>>, Justin Richer > <jricher@mit.edu <mailto:jricher@mit.edu>> > *Subject:*Re: [Id-event] Consensus :: Single Event > Syntax > > By your logic, JWT should be even worse of an > "interoperability disaster", but that doesn't seem > to be the case in practice. > > From: Richard Backman, Annabelle > > Sent: Thursday, December 14, 10:49 AM > > Subject: Re: [Id-event] Consensus :: Single Event > Syntax > > To: Phil Hunt, Mike Jones > > Cc: Benjamin Kaduk, Justin > Richer,id-event@ietf.org <mailto:id-event@ietf.org> > > Mike, > > What do you mean by “application”? A profiling > specification? A transmitter using a particular > profiling specification? A transmitter/receiver > pair using a profiling application? Something else? > > I’m not sure why you and Phil are bringing up > single vs. multi-aspect in your responses – the > point I’m making is that while you claim the > current draft supports multi-aspect SETs, its > syntax implies limitations on that support that > have not been acknowledged: > > By using a JSON object as a map with event types > as keys, it prohibits transmitters from including > two instances of the same event type in a single > SET. This reduces the scope of the events claim > from “aspects of a single logical event” to > “singleton aspects of a single logical event.”By > placing all event statements in a single layer > without hierarchy or any other indicator of > relationships, the syntax requires that receivers > be able to infer the correct relationships between > event statements. Consequently, either event > statements have to be entirely independent of one > another, define their own mechanism for > disambiguation, or transmitters have to take > special care to not produce SETs with ambiguous > combinations of event statements. > > It’s easy to dismiss interpretation of the events > claim as up to the > profile/receiver/”application”/etc., but if we do > not actually think through how profiles might use > the claim, and how someone would implement code to > interpret the claim, then we’re setting ourselves > up for an interoperability disaster. > > -- > > Annabelle Richard Backman > > Amazon – Identity Services > > *From:*Id-event <id-event-bounces@ietf.org > <mailto:id-event-bounces@ietf.org>> on behalf of > Phil Hunt <phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com>> > > *Date:*Thursday, December 14, 2017 at 9:32 AM > > *To:*Mike Jones <Michael.Jones@microsoft.com > <mailto:Michael.Jones@microsoft.com>> > > *Cc:*Benjamin Kaduk <bkaduk@akamai.com > <mailto:bkaduk@akamai.com>>, "Richard Backman, > Annabelle" <richanna@amazon.com > <mailto:richanna@amazon.com>>, Justin Richer > <jricher@mit.edu <mailto:jricher@mit.edu>>, > "id-event@ietf.org <mailto:id-event@ietf.org>" > <id-event@ietf.org <mailto:id-event@ietf.org>> > > *Subject:*Re: [Id-event] Consensus :: Single Event > Syntax > > +1 > > Phil > > On Dec 14, 2017, at 8:33 AM, Mike Jones > <Michael.Jones@microsoft.com > <mailto:Michael.Jones@microsoft.com>> wrote: > > I agree with Phil. If an application uses > multi-aspect SETs, it would be unsurprising > for them to generate or receive them. In other > applications, single-aspect SETS can be > specified, and in fact unexpected multi-aspect > SETs received can be rejected if appropriate > for the application. Both are possible – by > design. Both of Annabelle’s proposed > statements seem to be intruding into > application and profile design. The core SET > spec shouldn’t take a position on them either > way (just like the core JWT spec allows any > claims to be used by applications). > > -- Mike > > *From:*Id-event > [mailto:id-event-bounces@ietf.org]*On Behalf > Of*Benjamin Kaduk > > *Sent:*Thursday, December 14, 2017 7:50 AM > > *To:*Phil Hunt <phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com>>; Richard > Backman, Annabelle <richanna@amazon.com > <mailto:richanna@amazon.com>> > > *Cc:*id-event@ietf.org > <mailto:id-event@ietf.org>; Justin Richer > <jricher@mit.edu <mailto:jricher@mit.edu>> > > *Subject:*Re: [Id-event] Consensus :: Single > Event Syntax > > Sure, they're not your assertions; they're > Annabelle's assertions. But the question at > hand is whether you believe or disbelieve that > the assertions are true of the current draft > (and, if so, whether they should move from > implicit to explicit assumptions). > > It sounds like you are saying that you do not > believe the two assertions are true of the > current draft, but could you please be > explicit about your personal beliefs (as > opposed to Mike's)? > > Thanks, > > Ben > > On 12/13/2017 08:39 PM, Phil Hunt wrote: > > Those aren’t my assertions. > > The draft is written based on group input. > So no, not everything is backed directly > by case. It is backed by consensus. > > Mike’s comments that just like JWT’s can > have different content per audience, so > can a stream of SET per receiver. So > single event only SETs and multi-aspect > SETs are possible. > > If the receiver wants multi-aspect SETs, I > doubt they would find them ambiguous. > > Phil > > Oracle Corporation, Identity Cloud > Services Architect > > @independentid > > www.independentid.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=85cyhAYmmz380nKWOgwzhl0dZmKMtiFnEEge6fiK1rA&s=iccVyyTJcw_ZwESlqJw6m2HkrrnU0xd4xZjIbfavofA&e=> > > phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com> > > On Dec 13, 2017, at 5:54 PM, Richard > Backman, Annabelle > <richanna@amazon.com > <mailto:richanna@amazon.com>> wrote: > > The ones in my previous email (quoted > below): > > The current syntax doesn’t even work > for the professed use case, without > two unstated constraints: > > 1. Two instances of a single > type of event statement cannot be > related to the same logical event. > > 2. The combination of event > statements cannot be ambiguous. > > If the current draft intends to impose > these limits, they need to be stated > in the text. But more importantly, > what is the basis for imposing these > limitations on SET in the first place? > > -- > > Annabelle Richard Backman > > Amazon – Identity Services > > *From: *Phil Hunt > <phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com>> > > *Date: *Wednesday, December 13, 2017 > at 5:53 PM > > *To: *"Richard Backman, Annabelle" > <richanna@amazon.com > <mailto:richanna@amazon.com>> > > *Cc: *Justin Richer <jricher@mit.edu > <mailto:jricher@mit.edu>>, > "id-event@ietf.org > <mailto:id-event@ietf.org>" > <id-event@ietf.org > <mailto:id-event@ietf.org>> > > *Subject: *Re: [Id-event] Consensus :: > Single Event Syntax > > What restrictions are you referring to? > > Phil > > Oracle Corporation, Identity Cloud > Services Architect > > @independentid > > www.independentid.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=HKiKUZgXDLuGHjfG_wYgXCVNOctJXueCEh63hvF_ixc&s=nvU8oqF7Izoh-0sBdFy3FOwGW-pNlwpynSj4aet5atE&e=> > > phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com> > > > On Dec 13, 2017, at 5:46 PM, > Richard Backman, Annabelle > <richanna@amazon.com > <mailto:richanna@amazon.com>> wrote: > > Phil, > > As the author of the current > draft, can you clarify whether > these restrictions are > intentional, and if so why the use > cases for SET are being restricted > in this way? > > -- > > Annabelle Richard Backman > > Amazon – Identity Services > > *From: *"Richard Backman, > Annabelle" <richanna@amazon.com > <mailto:richanna@amazon.com>> > > *Date: *Monday, December 11, 2017 > at 10:09 AM > > *To: *Justin Richer > <jricher@mit.edu > <mailto:jricher@mit.edu>>, > "id-event@ietf.org > <mailto:id-event@ietf.org>" > <id-event@ietf.org > <mailto:id-event@ietf.org>> > > *Subject: *Re: [Id-event] > Consensus :: Single Event Syntax > > The current syntax doesn’t even > work for the professed use case, > without two unstated constraints: > > Two instances of a single type of > event statement cannot be related > to the same logical event. The > combination of event statements > cannot be ambiguous. > > If the current draft intends to > impose these limits, they need to > be stated in the text. But more > importantly, what is the basis for > imposing these limitations on SET > in the first place? > > -- > > Annabelle Richard Backman > > Amazon – Identity Services > > *From: *Id-event > <id-event-bounces@ietf.org > <mailto:id-event-bounces@ietf.org>> > on behalf of Justin Richer > <jricher@mit.edu > <mailto:jricher@mit.edu>> > > *Date: *Saturday, December 9, 2017 > at 6:04 AM > > *To: *"id-event@ietf.org > <mailto:id-event@ietf.org>" > <id-event@ietf.org > <mailto:id-event@ietf.org>> > > *Subject: *Re: [Id-event] > Consensus :: Single Event Syntax > > So the current syntax doesn't work > for Tony's stated use case of even > bundles while the new syntax does, > then. > > On 12/5/2017 5:50 PM, Mike Jones > wrote: > > The “events” claim definition > is already clear that the > “events” values convey > multiple aspects of a single > logical event - not > independent events. Section > 2.1 (Core Set Claims) says: > > events > > The semantics of this claim is > to define a set of event > statements > > that each MAY add additional > claims to fully describe a single > > logical event that has > occurred (e.g. a state change to a > > subject). … The "events" claim > SHOULD NOT be used to express > > multiple logical events. > > You’re describing a > theoretical problem that’s not > actually present in the > working group spec. > > -- Mike > > *From:* Richard Backman, > Annabelle > [mailto:richanna@amazon.com] > > *Sent:* Tuesday, December 5, > 2017 2:06 PM > > *To:* Mike Jones > <Michael.Jones@microsoft.com> > <mailto:Michael.Jones@microsoft.com>; > Phil Hunt > <phil.hunt@oracle.com> > <mailto:phil.hunt@oracle.com> > > *Cc:* William Denniss > <wdenniss@google.com> > <mailto:wdenniss@google.com>;M.Lizar@OCG > <mailto:M.Lizar@OCG> > <m.lizar@openconsentgroup.com> > <mailto:m.lizar@openconsentgroup.com>; > Yaron Sheffer > <yaronf.ietf@gmail.com> > <mailto:yaronf.ietf@gmail.com>; > Dick Hardt > <dick.hardt@gmail.com> > <mailto:dick.hardt@gmail.com>; > SecEvent <id-event@ietf.org> > <mailto:id-event@ietf.org> > > *Subject:* Re: [Id-event] > Consensus :: Single Event Syntax > > Once again, I am not talking > about the meaning of a given > event type or its contents. > I’m talking about the meaning > of putting an event in an > “events” claim alongside > another event in the same SET. > > Drawing an analogy to > programming, I’m talking about > defining what the syntax > “function_x() && function_y()” > means. Regardless of what > “function_x” and “function_y” > mean, the language defines the > meaning of that syntax as > “true if the result of > function_x is true and the > result of function_y is true.” > > -- > > Annabelle Richard Backman > > Amazon – Identity Services > > *From: *Mike Jones > <Michael.Jones@microsoft.com > <mailto:Michael.Jones@microsoft.com>> > > *Date: *Tuesday, December 5, > 2017 at 1:30 PM > > *To: *Phil Hunt > <phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com>>, > "Richard Backman, Annabelle" > <richanna@amazon.com > <mailto:richanna@amazon.com>> > > *Cc: *William Denniss > <wdenniss@google.com > <mailto:wdenniss@google.com>>, > "M.Lizar@OCG > <mailto:M.Lizar@OCG>" > <m.lizar@openconsentgroup.com > <mailto:m.lizar@openconsentgroup.com>>, > Yaron Sheffer > <yaronf.ietf@gmail.com > <mailto:yaronf.ietf@gmail.com>>, > Dick Hardt > <dick.hardt@gmail.com > <mailto:dick.hardt@gmail.com>>, > SecEvent <id-event@ietf.org > <mailto:id-event@ietf.org>> > > *Subject: *RE: [Id-event] > Consensus :: Single Event Syntax > > Hi Annabelle, > > The data contained in a SET > and the semantics of that data > will **always** be > profile-specific. That’s a > feature – not a bug. It’s > what makes SETs > general-purpose, rather than > being suited only for a narrow > set of use cases. > > An analogy with JWTs is > applicable. JWTs have no > required claims, so their > usage is always > profile-specific. That has > enabled them to be adopted by > numerous diverse applications. > SETs currently have that same > level of flexibility – by design. > > -- Mike > > *From:* Phil Hunt > [mailto:phil.hunt@oracle.com] > > *Sent:* Tuesday, December 5, > 2017 1:22 PM > > *To:* Richard Backman, > Annabelle <richanna@amazon.com > <mailto:richanna@amazon.com>> > > *Cc:* Mike Jones > <Michael.Jones@microsoft.com > <mailto:Michael.Jones@microsoft.com>>; > William Denniss > <wdenniss@google.com > <mailto:wdenniss@google.com>>; > M.Lizar@OCG > <mailto:M.Lizar@OCG> <m.lizar@openconsentgroup.com > <mailto:m.lizar@openconsentgroup.com>>; > Yaron Sheffer > <yaronf.ietf@gmail.com > <mailto:yaronf.ietf@gmail.com>>; > Dick Hardt > <dick.hardt@gmail.com > <mailto:dick.hardt@gmail.com>>; > SecEvent <id-event@ietf.org > <mailto:id-event@ietf.org>> > > *Subject:* Re: [Id-event] > Consensus :: Single Event Syntax > > I would disagree strongly with > the notion of > inter-operability requirements > on expected outcomes or > actions by receivers. > > SETs are statements of changes > in state of security objects > by transmitters. SETs do not > indicate any specific actions > that should be taken by > receivers. > > I believe I’ve covered this > issue during the informal BOF > (at the SCIM WG meeting > Argentina) and several times > during IETF WG meeting > presentations. I did so, > because within the IETF > community many people have > vastly different notions of > what an event is. > > Phil > > Oracle Corporation, Identity > Cloud Services Architect > > @independentid > > www.independentid.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=prG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ&s=tqqw1ywr-k_fQTVlTIQ-V24SRkRzlh5clMJQKLMLANw&e=> > > phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com> > > > > > > On Dec 5, 2017, at 12:57 > PM, Richard Backman, > Annabelle > <richanna@amazon.com > <mailto:richanna@amazon.com>> > wrote: > > Mike, > > This isn’t simply an issue > of “single vs multiple” – > the current draft is > fundamentally broken from > an interoperability > standpoint, because the > correct interpretation of > the “events” claim is at > best profile-specific, at > worst implementation-specific. > > -- > > Annabelle Richard Backman > > Amazon – Identity Services > > *From: *Mike Jones > <Michael.Jones@microsoft.com > <mailto:Michael.Jones@microsoft.com>> > > *Date: *Tuesday, December > 5, 2017 at 12:22 PM > > *To: *"Richard Backman, > Annabelle" > <richanna@amazon.com > <mailto:richanna@amazon.com>>, > William Denniss > <wdenniss@google.com > <mailto:wdenniss@google.com>>, > "M.Lizar@OCG > <mailto:M.Lizar@OCG>" > <m.lizar@openconsentgroup.com > <mailto:m.lizar@openconsentgroup.com>> > > *Cc: *Yaron Sheffer > <yaronf.ietf@gmail.com > <mailto:yaronf.ietf@gmail.com>>, > Phil Hunt > <phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com>>, > SecEvent > <id-event@ietf.org > <mailto:id-event@ietf.org>>, > Dick Hardt > <dick.hardt@gmail.com > <mailto:dick.hardt@gmail.com>> > > *Subject: *RE: [Id-event] > Consensus :: Single Event > Syntax > > Morteza already pointed > out > <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_id-2Devent_KPaK5aN3EeIybWJmQOJiqdHXQzg&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=ZClAgy65x4a1O93YYenj_z_6Bxd_6sMzPOs8PLi06XA&e=> a > simple solution to > enabling SETs to contain > only a single event > description for profiles > that want that – a > solution proposed by Yaron > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00736.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=tac2j_cTgyBwnnfHNTPzlRUwOCjxvascShR4JfccwMg&e=> that > doesn’t involve making any > breaking changes: > Explicitly specify that > profiles can restrict the > number of elements in the > “events” data structure – > including limiting them to > one element, when > desired. Then profiles > that want this can have it > and profiles that need to > enable multiple aspects of > an event to be easily > represented can have that > too. Hopefully people can > rally around that > straightforward solution, > enabling us to move on and > finish the SET spec in as > timely a fashion as possible. > > -- Mike > > *From:* Id-event > [mailto:id-event-bounces@ietf.org] > *On Behalf Of *Richard > Backman, Annabelle > > *Sent:* Tuesday, December > 5, 2017 11:40 AM > > *To:* William Denniss > <wdenniss@google.com > <mailto:wdenniss@google.com>>; > M.Lizar@OCG > <mailto:M.Lizar@OCG> <m.lizar@openconsentgroup.com > <mailto:m.lizar@openconsentgroup.com>> > > *Cc:* Yaron Sheffer > <yaronf.ietf@gmail.com > <mailto:yaronf.ietf@gmail.com>>; > Phil Hunt > <phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com>>; > SecEvent > <id-event@ietf.org > <mailto:id-event@ietf.org>>; > Dick Hardt > <dick.hardt@gmail.com > <mailto:dick.hardt@gmail.com>> > > *Subject:* Re: [Id-event] > Consensus :: Single Event > Syntax > > William’s email analogy > demonstrates the problem > with the current syntax: > imagine if the text part > of a multi-part email > could be any of the > following, with no > explicit indication which > one it is: > > A plaintext representation > of the same content in the > HTML part. The CSS to use > when rendering the HTML > part. Annotations on the > contents of the HTML > part. A vCard for the > sender of the message. A > completely separate > message with a separate > subject line embedded in > the text. > > How would a mail reader > know what to do with this? > It couldn’t, not in any > scalable way. Yet is > exactly the situation we > will have, given the > current draft and the way > people are proposing using > its multi-part capability: > > William wants to use it to > send different independent > representations of the > same event. Phil wants to > use it to send different > aspects of the same event, > intended to be processed > together. Tony wants to > use it for directory > synchronization. Marius > wants to use it to send > the same event under both > standard and deprecated > names. et cetera, et cetera… > > This confusion is going to > limit reusability and > interoperability, and > hinder adoption. If the WG > consensus is that all > these use cases are in > scope for SET, that’s > fine, we can support them > – but we need to do so in > a way that doesn’t create > complete chaos. > > At risk of repeating > myself, maybe we need to > have a consensus > discussion on which > multi-part use cases are > in scope for SET before we > continue with this discussion? > > -- > > Annabelle Richard Backman > > Amazon – Identity Services > > *From: *Id-event > <id-event-bounces@ietf.org > <mailto:id-event-bounces@ietf.org>> > on behalf of William > Denniss > <wdenniss@google.com > <mailto:wdenniss@google.com>> > > *Date: *Monday, December > 4, 2017 at 7:20 PM > > *To: *"M.Lizar@OCG > <mailto:M.Lizar@OCG>" > <m.lizar@openconsentgroup.com > <mailto:m.lizar@openconsentgroup.com>> > > *Cc: *Yaron Sheffer > <yaronf.ietf@gmail.com > <mailto:yaronf.ietf@gmail.com>>, > Dick Hardt > <dick.hardt@gmail.com > <mailto:dick.hardt@gmail.com>>, > SecEvent > <id-event@ietf.org > <mailto:id-event@ietf.org>>, > Phil Hunt > <phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com>> > > *Subject: *Re: [Id-event] > Consensus :: Single Event > Syntax > > I would prefer to keep the > format in the current > working group draft. > > Based on the requirement > that events may be > represented in multiple > ways, I believe having > both formats carried in a > single SET is superior as > it avoids complex linking > logic. The best analogy I > can think of is email, > where MIME allows for text > and html versions *of the > same content* to be > carried in a single email > (much like how SET allows > for multiple > representations *of the > same event* in a SET). > With email, the > recipient's client is then > able to display the > version it prefers from > those available. Imagine > the additional logic if > every email was sent twice > – e.g. what if the plain > text version arrives, the > HTML one is delayed? How > should the client react if > the HTML version arrives > later, would it replace > the version it had? What > if you were already > viewing and/or replying? > > Time-wise I'm really > concerned if we don't lock > this down soon, the people > who are waiting on us to > profile SET will walk away > and do their own thing (I > was worried about that a > year ago… and I think > we've waited long enough). > I think we should keep > this in mind and choose > the path that will have > the fastest resolution. If > the decision was to change > the format at this late > stage, I would like to > hear what steps can be > done to avoid additional > delay. > > I really respect the work > Annabelle has done in > leading the alternative > representation, and I do > think it’s a viable > alternative. If we choose > to change the spec and go > with the singular option, > then I think the > requirement of multiple > representations should be > dropped, or at a minimum > de-emphasized as this > (along with expediency) is > the main reason I believe > the existing format is better. > > On Mon, Dec 4, 2017 at > 1:08 PM, M.Lizar@OCG > <mailto:M.Lizar@OCG> <m.lizar@openconsentgroup.com > <mailto:m.lizar@openconsentgroup.com>> > wrote: > > Small typo, - should > be a ‘.’ Not a ‘?’ > > The spec works well > for the consent a > privacy syntax use > cases we are aware of > (full stop) > > - Mark > > On 4 Dec 2017, at > 20:46, M.Lizar@OCG > <mailto:M.Lizar@OCG> <m.lizar@openconsentgroup.com > <mailto:m.lizar@openconsentgroup.com>> > wrote: > > I concur with Mike > and Justin, we had > the same issue > with primary and > secondary in the > Consent Receipt spec. > > We are > also opposed to > making breaking > changes at this > late date and that > the existing > working group spec > already works well > for the consent > and privacy use > cases we are aware > of? > > Mark Lizar | CEO > Open Consent | > Co-Char CISWG at > Kantara > > On 1 Dec 2017, > at 18:35, Phil > Hunt > <phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com>> > wrote: > > For historical > purposes, this > has been > discussed > twice before > (once at the > request of > Annabelle). > > I think it > would be > helpful, why, > after WGLC, > this issue is > being brought > forward yet > again. Dick > has stated > that > Annabelle’s > concern that > she finds it > difficult to > implement is > sufficient. > Yet, I’m not > sure we are > entertaining a > new concern > here. No new > information > was provided. > > I note that at > the time, the > chairs did not > feel there was > a lack of > consensus in > order to call > for one in the > past. > > On some of > these matters, > the choice may > be arbitrary, > and that is > why I think > keeping track > of prior > discussion is > important so > that we can > clearly move > forward and > not repeat > discussion of > the past > further > confusing > consensus. > > While I > advocated for > singular > events as a > possibility in > the past, I > now have much > more stronger > technical > reasons for > the WG draft > design, which > have > strengthened > rather than > weakened in > the past week. > I will share > these later, > after the > minutes have > been published. > > On Dec 10, > 2016, Yaron > while > reviewing the > ID > draft-hunt-idevent-token-07 > [1]: > > * Why > "events" > and > not > "event"? > We > don't > really > have > support > for > multiple > events. > Certainly > not if > they > are > all of > the > same > type. > The > current > text > is > confusing: > "events" > is not > the > same > as "a > primary > event > and > its > extensions”. > > [MIKE] > Reflects > your > earlier > comment > re: > primary > vs. > extensions. > "events” > is plural > to reflect > the fact > that the > attribute > is > multi-valued. > I agree, > given that > only one > primary > event can > be > included, > the naming > is misleading. > > >From later in the > thread [2]: > > * > 2: > "first > value" > is > meaningless. > JSON > objects > are > unordered > (4th > > > > paragraph > of > RFC > 7159). > If > order > /is/ > important, > we > could > make > > > > "events" > into > an > array. > > > > _[Phil] > _ > > > > Yup. > How > would > the > group > like > to > fix > this? > We > could > make > “events” > > > > singular > and > have > an > extensions > attribute > to > hold > the > extensions. > Or we > > > > could > go > to > a > more > complex > JSON > structure > (not > personally > a > fan). > > > > _[Yaron]_ > > > > I'm > personally > fine > with a > main > "event" > object > and an > "extensions" > attribute. > I can > even > live > with > "event" > being > called > "events", > per > Mike's > proposal. > But > the > structure > needs > to > make > sense > as a > JSON > object > if we > want > it > implemented. > > > > > > [PH] > Thread: > Should the > primary > event be a > separate > attribute? > > > > > > We had > this > broken out > before. If > there is > sufficient > desire to > break it > out again, > I have no > objection. > > > > Then following > WG adoption, I > re-reraised > the issue > after > discussion > with Annabelle > draft-secevent-token-00 > [3]: > > On this > topic, > following > Yaron’s > comments > Mike Jones > raised > some > points > that there > should be > no > distinction > between > primary > events and > extensions > (https://mailarchive.ietf.org/arch/msg/id-event/0Hhg46ROcidQDLL7OnXUs88TJ9U > <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_id-2Devent_0Hhg46ROcidQDLL7OnXUs88TJ9U&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=8DBZ5hsA4WNFez3mJr2W9TW0WCYTWMbY1Vs5sgcIauQ&e=>). > Summarizing: > > * > Processors > will run > through > all of > them > regardless. > It is not > necessarily > helpful to > understand > which is a > primary > vs. extension > > * Let’s > drop > distinction > between > primary > vs. > extension. > You can > simply > express > one or > more sets > of event > attributes > in a > single JWT > > My > proposal > is to drop > this > terminology > in the > text and > keep the > attribute > multi-valued. > The > purpose of > the > attribute > is to > inform the > reader > what > events are > being > asserted > and what > additional > data may > be > present. > It is up > to the > reader to > ultimately > infer > meaning > when one > or more > URIs are > present. > Further, > when > multiple > URIs are > present it > must still > to make a > combined > statement > about a > single > state > change > about a > subject. > It must > not be > used to > convey > multiple > distinct > (e.g. > transactions) > events > about a > subject. > > Assuming > everyone > agrees, I > will plan > to remove > these > distinctions > in the > next > update > with some > new text. > Please > comment if > you have > concerns. > > To which Mike > Jones > responded [4] > > I believe > we already > had > consensus > to drop > the > primary/secondary > distinction, > which we > intentionally > did before > adoption > of the > working > group > draft. I > believe > any such > distinction > will both > be > unhelpful > and result > in > syntactic > complexity. > Please > let’s > finish > stamping > out the > notion > that any > of the > events in > a SET are > somehow > different > than the > others. > > William > Denniss wrote > [5]: > > I agree > with your > proposal. > > They're > all just > events. Up > to > implementors > to define > & > categorize > their > events how > they like. > > Marius also > agreed (he may > have switched > positions now) > [6]: > > I also > think it > makes > sense to > remove the > primary/secondary > distinction. > > Marius > > Justin also > agreed (and > may have > switched > positions) [7] > > +1, drop > "primary" > and keep > it an object > > -- Justin > > References: > > [1] - > https://www.ietf.org/mail-archive/web/id-event/current/msg00298.html > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00298.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=rG_9NWsC86NC5EDI8paY2lIrUkHUirGG3jfmoHhYAw8&e=> > > [2] - > https://www.ietf.org/mail-archive/web/id-event/current/msg00299.html > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00299.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=wE8wEkrp-0wxrzKFqozLAsjsD2qgA2mCoDZQp5lwqdA&e=> > > [3] - > https://www.ietf.org/mail-archive/web/id-event/current/msg00345.html > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00345.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=QEGxsGOAn3D6pmmzeLtQ_gkOSgxpq-8ce2CbXfe2Zk8&e=> > > [4] - > https://www.ietf.org/mail-archive/web/id-event/current/msg00347.html > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00347.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=IcdLUKGzpKm8QwfE2mo-NufvoiWgjsj__BKRvGGod8c&e=> > > [5] - > https://www.ietf.org/mail-archive/web/id-event/current/msg00349.html > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00349.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=d0uNsjizWSlLYksDHdqZaYC6Ix0OMDltFs2e4QjTJJE&e=> > > [6] - > https://www.ietf.org/mail-archive/web/id-event/current/msg00365.html > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00365.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=_FtWiNomXopU9A9_k7A1nsjMQfaXZ_ZjxgBxNrhUBIQ&e=> > > [7] - > https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00406.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=k5JC5HYCfm0BtQJar8_ZAKRUzgUsJYaCbtiLWOkWxJc&e=> > > Phil > > Oracle > Corporation, > Identity Cloud > Services Architect > > @independentid > > www.independentid.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=zQiT4vu41M1sH4KXtpfMbiC5yDIIPxJ8Vp35knc8EHk&e=> > > phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com> > > On Dec 1, > 2017, at > 8:50 AM, > Dick Hardt > <dick.hardt@gmail.com > <mailto:dick.hardt@gmail.com>> > wrote: > > Is it > important > to > syntactically > ensure > that only > one event > is in a SET? > > For > privacy > reasons, > some use > cases want > to ensure > that only > one signal > is in a SET. > > This adds > some > additional > complexity > for use > cases that > want to > include > multiple > signals in > a SET. > > See > https://tools.ietf.org/html/draft-backman-secevent-token-02 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbackman-2Dsecevent-2Dtoken-2D02&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=P-rrbMomS-aMBQQ0HPfPzvNPkWHLDYs8SsugRHx-eLM&e=> for > an > proposed > syntax > that > ensures > one event > per SET, > and > enables > multiple > events per > SET when > desired > > We will > track > results > here: > https://github.com/IETF-SecEvent/Drafts/issues/1 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=3f7fFs9ZKZrg1ScI3Ml2r8ykvHGuBbup831kDUNklfw&e=> > > Discussion > to be on > the mail > list as > usual, not > in the > issue tracker! > > /Dick > > _______________________________________________ > > Id-event > mailing list > > Id-event@ietf.org > <mailto:Id-event@ietf.org> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=YnAKATJz3qVYniVaDUIMtQb9L-vMocgsYARzV6axzq4&e= > > _______________________________________________ > > Id-event > mailing list > > Id-event@ietf.org > <mailto:Id-event@ietf.org> > > https://www.ietf.org/mailman/listinfo/id-event > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=> > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > <mailto:Id-event@ietf.org> > > https://www.ietf.org/mailman/listinfo/id-event > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=> > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > <mailto:Id-event@ietf.org> > > https://www.ietf.org/mailman/listinfo/id-event > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=> > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > <mailto:Id-event@ietf.org> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e= > > > > > > > > _______________________________________________ > Id-event mailing > listId-event@ietf.org > <mailto:Id-event@ietf.org>https://www.ietf.org/mailman/listinfo/id-event > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=prG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ&s=71lmYUkVWVH_HWBqDK_xmuhgzUM2-OqKqWNJ8D0lmTc&e=> > > > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > <mailto:Id-event@ietf.org> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=prG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ&s=71lmYUkVWVH_HWBqDK_xmuhgzUM2-OqKqWNJ8D0lmTc&e= > > > > > _______________________________________________ > Id-event mailing listId-event@ietf.org > <mailto:Id-event@ietf.org>https://www.ietf.org/mailman/listinfo/id-event > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=vfhSbt7MosGc8EBa0PTWz8y-Ut109JH4J14kRCIbzoY&s=oZbMC2L9fLzIytCmnBbmTr-5gpMEmLVSa2o_jzR-cA8&e=> > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org <mailto:Id-event@ietf.org> > https://www.ietf.org/mailman/listinfo/id-event >
- [Id-event] Consensus :: Single Event Syntax Dick Hardt
- Re: [Id-event] Consensus :: Single Event Syntax Phil Hunt
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Phil Hunt
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Mike Jones
- Re: [Id-event] Consensus :: Single Event Syntax Morteza Ansari (moransar)
- Re: [Id-event] Consensus :: Single Event Syntax John Bradley
- Re: [Id-event] Consensus :: Single Event Syntax John Bradley
- Re: [Id-event] Consensus :: Single Event Syntax Nat Sakimura
- Re: [Id-event] Consensus :: Single Event Syntax M.Lizar@OCG
- Re: [Id-event] Consensus :: Single Event Syntax M.Lizar@OCG
- Re: [Id-event] Consensus :: Single Event Syntax William Denniss
- Re: [Id-event] Consensus :: Single Event Syntax Justin Richer
- Re: [Id-event] Consensus :: Single Event Syntax Justin Richer
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Mike Jones
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Phil Hunt
- Re: [Id-event] Consensus :: Single Event Syntax Mike Jones
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Mike Jones
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Phil Hunt
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Phil Hunt
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Phil Hunt
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Morteza Ansari (moransar)
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax John Wunderlich
- Re: [Id-event] Consensus :: Single Event Syntax Marius Scurtescu
- Re: [Id-event] Consensus :: Single Event Syntax Marius Scurtescu
- Re: [Id-event] Consensus :: Single Event Syntax Marius Scurtescu
- Re: [Id-event] Consensus :: Single Event Syntax Marius Scurtescu
- Re: [Id-event] Consensus :: Single Event Syntax Justin Richer
- Re: [Id-event] Consensus :: Single Event Syntax Justin Richer
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Anthony Nadalin
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Phil Hunt
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Phil Hunt
- Re: [Id-event] Consensus :: Single Event Syntax Benjamin Kaduk
- Re: [Id-event] Consensus :: Single Event Syntax Mike Jones
- Re: [Id-event] Consensus :: Single Event Syntax Phil Hunt
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Mike Jones
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Phil Hunt
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Marius Scurtescu
- Re: [Id-event] Consensus :: Single Event Syntax Justin Richer
- Re: [Id-event] Consensus :: Single Event Syntax Mike Jones
- Re: [Id-event] Consensus :: Single Event Syntax Marius Scurtescu
- Re: [Id-event] Consensus :: Single Event Syntax Phil Hunt
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Phil Hunt
- Re: [Id-event] Consensus :: Single Event Syntax Marius Scurtescu
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Justin Richer
- Re: [Id-event] Consensus :: Single Event Syntax Mike Jones
- Re: [Id-event] Consensus :: Single Event Syntax Justin Richer
- Re: [Id-event] Consensus :: Single Event Syntax Phil Hunt
- Re: [Id-event] Consensus :: Single Event Syntax Anthony Nadalin
- Re: [Id-event] Consensus :: Single Event Syntax Richard Backman, Annabelle
- Re: [Id-event] Consensus :: Single Event Syntax Adam Dawes
- Re: [Id-event] Consensus :: Single Event Syntax Leif Johansson