Re: [Id-event] Consensus :: Single Event Syntax

[Anthony Nadalin <[e-mail]>]

+1

From: Id-event [mailto:[e-mail]] On Behalf Of Phil Hunt
Sent: Monday, December 18, 2017 7:51 AM
To: Justin Richer <[e-mail]>
Cc: Benjamin Kaduk <[e-mail]>; Mike Jones <[e-mail]>; Richard Backman, Annabelle <[e-mail]>; [e-mail]; Marius Scurtescu <[e-mail]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

I agree with Mike.

I do not find this proposal workable because it excludes the requirements of many with running code now.

Further since implementers are following the wg draft they should not have to continually justify themselves. Those that seek to break implementation must justify.

The only concern i heard is easily mitigated by allowing a receiver to indicate desire for single event SETs. This does not break running code.

Phil

On Dec 18, 2017, at 6:34 AM, Justin Richer <[e-mail]<mailto:[e-mail]>> wrote:

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:[e-mail]]
Sent: Sunday, December 17, 2017 11:41 AM
To: Marius Scurtescu <[e-mail]><mailto:[e-mail]>
Cc: Mike Jones <[e-mail]><mailto:[e-mail]>; Richard Backman, Annabelle <[e-mail]><mailto:[e-mail]>; Phil Hunt <[e-mail]><mailto:[e-mail]>; Benjamin Kaduk <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
Sent: Friday, December 15, 2017 7:09 AM
To: Marius Scurtescu <[e-mail]<mailto:[e-mail]>>
Cc: Richard Backman, Annabelle <[e-mail]<mailto:[e-mail]>>; Phil Hunt <[e-mail]<mailto:[e-mail]>>; Mike Jones <[e-mail]<mailto:[e-mail]>>; Benjamin Kaduk <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:

On Thu, Dec 14, 2017 at 3:03 PM, Richard Backman, Annabelle <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: Thursday, December 14, 2017 at 1:14 PM
To: "Richard Backman, Annabelle" <[e-mail]<mailto:[e-mail]>>
Cc: Mike Jones <[e-mail]<mailto:[e-mail]>>, Benjamin Kaduk <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Justin Richer <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> on behalf of Mike Jones <[e-mail]<mailto:[e-mail]>>
Date: Thursday, December 14, 2017 at 11:04 AM
To: Phil Hunt <[e-mail]<mailto:[e-mail]>>, "Richard Backman, Annabelle" <[e-mail]<mailto:[e-mail]>>
Cc: Benjamin Kaduk <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Justin Richer <[e-mail]<mailto:[e-mail]>>
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, [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> on behalf of Phil Hunt <[e-mail]<mailto:[e-mail]>>
Date: Thursday, December 14, 2017 at 9:32 AM
To: Mike Jones <[e-mail]<mailto:[e-mail]>>
Cc: Benjamin Kaduk <[e-mail]<mailto:[e-mail]>>, "Richard Backman, Annabelle" <[e-mail]<mailto:[e-mail]>>, Justin Richer <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

+1
Phil
On Dec 14, 2017, at 8:33 AM, Mike Jones <[e-mail]<mailto:[e-mail]>> 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:[e-mail]] On Behalf Of Benjamin Kaduk
Sent: Thursday, December 14, 2017 7:50 AM
To: Phil Hunt <[e-mail]<mailto:[e-mail]>>; Richard Backman, Annabelle <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Justin Richer <[e-mail]<mailto:[e-mail]>>
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.independentid.com%26d%3DDwMFaQ%26c%3D96ZbZZcaMF4w0F4jpN6LZg%26r%3DsssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM%26m%3D85cyhAYmmz380nKWOgwzhl0dZmKMtiFnEEge6fiK1rA%26s%3DiccVyyTJcw_ZwESlqJw6m2HkrrnU0xd4xZjIbfavofA%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=RAss9kQt3vHc%2F28dp7jQnQOHwuckpv5nIMGTSEt2XQo%3D&reserved=0>
[e-mail]<mailto:[e-mail]>


On Dec 13, 2017, at 5:54 PM, Richard Backman, Annabelle <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, December 13, 2017 at 5:53 PM
To: "Richard Backman, Annabelle" <[e-mail]<mailto:[e-mail]>>
Cc: Justin Richer <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.independentid.com%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DHKiKUZgXDLuGHjfG_wYgXCVNOctJXueCEh63hvF_ixc%26s%3DnvU8oqF7Izoh-0sBdFy3FOwGW-pNlwpynSj4aet5atE%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=zppcinIb1W16NlovqbRyJ%2FzXF6QyyYFnpGPh%2BKHRuUo%3D&reserved=0>
[e-mail]<mailto:[e-mail]>



On Dec 13, 2017, at 5:46 PM, Richard Backman, Annabelle <[e-mail]<mailto:[e-mail]>> 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" <[e-mail]<mailto:[e-mail]>>
Date: Monday, December 11, 2017 at 10:09 AM
To: Justin Richer <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> on behalf of Justin Richer <[e-mail]<mailto:[e-mail]>>
Date: Saturday, December 9, 2017 at 6:04 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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:[e-mail]]
Sent: Tuesday, December 5, 2017 2:06 PM
To: Mike Jones <[e-mail]><mailto:[e-mail]>; Phil Hunt <[e-mail]><mailto:[e-mail]>
Cc: William Denniss <[e-mail]><mailto:[e-mail]>; M.Lizar@OCG<mailto:M.Lizar@OCG> <[e-mail]><mailto:[e-mail]>; Yaron Sheffer <[e-mail]><mailto:[e-mail]>; Dick Hardt <[e-mail]><mailto:[e-mail]>; SecEvent <[e-mail]><mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, December 5, 2017 at 1:30 PM
To: Phil Hunt <[e-mail]<mailto:[e-mail]>>, "Richard Backman, Annabelle" <[e-mail]<mailto:[e-mail]>>
Cc: William Denniss <[e-mail]<mailto:[e-mail]>>, "M.Lizar@OCG<mailto:M.Lizar@OCG>" <[e-mail]<mailto:[e-mail]>>, Yaron Sheffer <[e-mail]<mailto:[e-mail]>>, Dick Hardt <[e-mail]<mailto:[e-mail]>>, SecEvent <[e-mail]<mailto:[e-mail]>>
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:[e-mail]]
Sent: Tuesday, December 5, 2017 1:22 PM
To: Richard Backman, Annabelle <[e-mail]<mailto:[e-mail]>>
Cc: Mike Jones <[e-mail]<mailto:[e-mail]>>; William Denniss <[e-mail]<mailto:[e-mail]>>; M.Lizar@OCG<mailto:M.Lizar@OCG> <[e-mail]<mailto:[e-mail]>>; Yaron Sheffer <[e-mail]<mailto:[e-mail]>>; Dick Hardt <[e-mail]<mailto:[e-mail]>>; SecEvent <[e-mail]<mailto:[e-mail]>>
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.independentid.com%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DprG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ%26s%3Dtqqw1ywr-k_fQTVlTIQ-V24SRkRzlh5clMJQKLMLANw%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=dZvF4mYHssVCopMsXbco5XqKsXowyDc4Smbit6Y3ixw%3D&reserved=0>
[e-mail]<mailto:[e-mail]>






On Dec 5, 2017, at 12:57 PM, Richard Backman, Annabelle <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, December 5, 2017 at 12:22 PM
To: "Richard Backman, Annabelle" <[e-mail]<mailto:[e-mail]>>, William Denniss <[e-mail]<mailto:[e-mail]>>, "M.Lizar@OCG<mailto:M.Lizar@OCG>" <[e-mail]<mailto:[e-mail]>>
Cc: Yaron Sheffer <[e-mail]<mailto:[e-mail]>>, Phil Hunt <[e-mail]<mailto:[e-mail]>>, SecEvent <[e-mail]<mailto:[e-mail]>>, Dick Hardt <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Id-event] Consensus :: Single Event Syntax

Morteza already pointed out<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__mailarchive.ietf.org_arch_msg_id-2Devent_KPaK5aN3EeIybWJmQOJiqdHXQzg%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DZClAgy65x4a1O93YYenj_z_6Bxd_6sMzPOs8PLi06XA%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=zrUnAKpLa4P8HGMX1ba3tJim0gFm6bT7o7e5W7L5tNY%3D&reserved=0> a simple solution to enabling SETs to contain only a single event description for profiles that want that – a solution proposed by Yaron<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00736.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3Dtac2j_cTgyBwnnfHNTPzlRUwOCjxvascShR4JfccwMg%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=xFcj%2Fz048ThM0h36t5O0GweZot0pj%2B8QtF8chKaBoOc%3D&reserved=0> 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:[e-mail]] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, December 5, 2017 11:40 AM
To: William Denniss <[e-mail]<mailto:[e-mail]>>; M.Lizar@OCG<mailto:M.Lizar@OCG> <[e-mail]<mailto:[e-mail]>>
Cc: Yaron Sheffer <[e-mail]<mailto:[e-mail]>>; Phil Hunt <[e-mail]<mailto:[e-mail]>>; SecEvent <[e-mail]<mailto:[e-mail]>>; Dick Hardt <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> on behalf of William Denniss <[e-mail]<mailto:[e-mail]>>
Date: Monday, December 4, 2017 at 7:20 PM
To: "M.Lizar@OCG<mailto:M.Lizar@OCG>" <[e-mail]<mailto:[e-mail]>>
Cc: Yaron Sheffer <[e-mail]<mailto:[e-mail]>>, Dick Hardt <[e-mail]<mailto:[e-mail]>>, SecEvent <[e-mail]<mailto:[e-mail]>>, Phil Hunt <[e-mail]<mailto:[e-mail]>>
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> <[e-mail]<mailto:[e-mail]>> 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> <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__mailarchive.ietf.org_arch_msg_id-2Devent_0Hhg46ROcidQDLL7OnXUs88TJ9U%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3D8DBZ5hsA4WNFez3mJr2W9TW0WCYTWMbY1Vs5sgcIauQ%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=EinEwfp9olMTa5LDfEETqp3Nx5%2F0DTfohq9pw%2BmO1C4%3D&reserved=0>).  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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00298.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DrG_9NWsC86NC5EDI8paY2lIrUkHUirGG3jfmoHhYAw8%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=2cUVhILq7B6oAnqTSIALGXgsAXK2Ak4m1ZWRfeUrMhg%3D&reserved=0>
[2] - https://www.ietf.org/mail-archive/web/id-event/current/msg00299.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00299.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DwE8wEkrp-0wxrzKFqozLAsjsD2qgA2mCoDZQp5lwqdA%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=dfd7BjuCDWtlqxsgFh09EZT6NR6c%2BP5LuAORVBH7wF0%3D&reserved=0>
[3] - https://www.ietf.org/mail-archive/web/id-event/current/msg00345.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00345.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DQEGxsGOAn3D6pmmzeLtQ_gkOSgxpq-8ce2CbXfe2Zk8%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=rRmMO0IvzgEUTXfDTXSc75tylTM3%2BnaJbyENki0hllI%3D&reserved=0>
[4] - https://www.ietf.org/mail-archive/web/id-event/current/msg00347.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00347.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DIcdLUKGzpKm8QwfE2mo-NufvoiWgjsj__BKRvGGod8c%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=rpLu7fjkx41x%2B0ersQTiqvMyY7UGqKO%2FkTfbtpFzWvA%3D&reserved=0>
[5] - https://www.ietf.org/mail-archive/web/id-event/current/msg00349.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00349.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3Dd0uNsjizWSlLYksDHdqZaYC6Ix0OMDltFs2e4QjTJJE%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=LMfPPOVpUrbhGm%2FSguTihmZAseD%2Bb21ZzjNJt0BUAjw%3D&reserved=0>
[6] - https://www.ietf.org/mail-archive/web/id-event/current/msg00365.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00365.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3D_FtWiNomXopU9A9_k7A1nsjMQfaXZ_ZjxgBxNrhUBIQ%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=Sy4H7kAwGCojVyOt9PQCs9c%2BXYH8Lcyv2udF6H5TukQ%3D&reserved=0>
[7] - https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00406.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3Dk5JC5HYCfm0BtQJar8_ZAKRUzgUsJYaCbtiLWOkWxJc%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=kis2mtAYghiv%2BAN4Ec19pyohazncI1p4O72OBqGgqpY%3D&reserved=0>

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.independentid.com_%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DzQiT4vu41M1sH4KXtpfMbiC5yDIIPxJ8Vp35knc8EHk%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=Y%2FlD6tPrGxemOTjVZ0CWjsUWIRUYxrih4otmI%2F1vNqU%3D&reserved=0>
[e-mail]<mailto:[e-mail]>

On Dec 1, 2017, at 8:50 AM, Dick Hardt <[e-mail]<mailto:[e-mail]>> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__tools.ietf.org_html_draft-2Dbackman-2Dsecevent-2Dtoken-2D02%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3Dp986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY%26s%3DP-rrbMomS-aMBQQ0HPfPzvNPkWHLDYs8SsugRHx-eLM%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=rvL543RbhjP74ogd09Qhve0wodNAqNdGo7hcF9I%2FPw4%3D&reserved=0> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_IETF-2DSecEvent_Drafts_issues_1%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3Dp986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY%26s%3D3f7fFs9ZKZrg1ScI3Ml2r8ykvHGuBbup831kDUNklfw%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=a8uSf2q7yE7M51pJvShbCl9pNY%2BqwcBbygU2OUzHzHg%3D&reserved=0>

Discussion to be on the mail list as usual, not in the issue tracker!

/Dick
_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
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=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwICAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3Dp986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY%26s%3DYnAKATJz3qVYniVaDUIMtQb9L-vMocgsYARzV6axzq4%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=B7mIaLTxxcgHLsPIgYL1MggTRi6xOSCOTEQQEH4ibCs%3D&reserved=0>

_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DoLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=CPpB%2BZsOlnji036LpWYVz0%2B0loVMM1lxxAHfuEZ76M4%3D&reserved=0>

_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DoLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=CPpB%2BZsOlnji036LpWYVz0%2B0loVMM1lxxAHfuEZ76M4%3D&reserved=0>

_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DoLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=CPpB%2BZsOlnji036LpWYVz0%2B0loVMM1lxxAHfuEZ76M4%3D&reserved=0>

_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
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=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwICAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DoLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=asRm4EX7HNwHB6dj3%2B9gsF5ML5RekVwAf1YLX5BA5SE%3D&reserved=0>







_______________________________________________ Id-event mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DprG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ%26s%3D71lmYUkVWVH_HWBqDK_xmuhgzUM2-OqKqWNJ8D0lmTc%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=96C9T6oxIu5bMmzUee1D8sCNXrAIymfa0NuN65a8VRM%3D&reserved=0>





_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
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=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwICAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DprG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ%26s%3D71lmYUkVWVH_HWBqDK_xmuhgzUM2-OqKqWNJ8D0lmTc%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=XuJQhPxzD6w22xxqghY0UqMKil%2F0OnzYytlIdZikV00%3D&reserved=0>





_______________________________________________ Id-event mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DvfhSbt7MosGc8EBa0PTWz8y-Ut109JH4J14kRCIbzoY%26s%3DoZbMC2L9fLzIytCmnBbmTr-5gpMEmLVSa2o_jzR-cA8%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=OSaNh7hBRjphjtzwDGZGDbkDA5sFPZ6k3GVFLT%2F%2BOXA%3D&reserved=0>



_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwMDaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DbL-BMACU7_BSuxL7lFUXZ7mW2U-CBM8gsw98jVyUhNQ%26s%3DKktPZzNYa1WjpEFVCZFZUd4S9hsvxYH7l9XoODfy1pY%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=bb0a7dz0UbOyUXgBDGd7glonC3aCpadlWmF6IyhJWS8%3D&reserved=0>




_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bL-BMACU7_BSuxL7lFUXZ7mW2U-CBM8gsw98jVyUhNQ&s=KktPZzNYa1WjpEFVCZFZUd4S9hsvxYH7l9XoODfy1pY&e=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwICAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DbL-BMACU7_BSuxL7lFUXZ7mW2U-CBM8gsw98jVyUhNQ%26s%3DKktPZzNYa1WjpEFVCZFZUd4S9hsvxYH7l9XoODfy1pY%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=to1kVk9mA92rVNu8Deo8phHQOrNbUhxG%2FO%2BtctOLd3w%3D&reserved=0>