Subject: [Id-event] Statement of historical fact, command, or distinction without a difference?

From: Mike Jones <[email-masked]>
Date: Mon, 27 Mar 2017 04:34:14 +0000

One of the things that's always bothered me about the SET spec is that it says:
"Security Events are not commands issued between parties.  A security event is a statement of fact from the perspective of an issuer about the state of a security subject (e.g., a web resource, token, IP address, the issuer itself) that the issuer controls or is aware of, that has changed in some way (explicitly or implicitly)."
Likewise, it includes "a SET reflects something that has already been processed and is historical in nature" and other similar statements.

Whether a SET is a historical statement of fact or a command has always seemed like a distinction without a difference in my mind.  I therefore propose that we strike that language from the SET spec because it's not actionable or testable.  For instance, whether a logout token is the statement "I the OP have logged out the end-user whose session identifier at your RP is abc123" with a resulting action taken by the RP to log out that session or whether the logout token is the command "Please logout the end-user whose session identifier at your RP is abc123" with the same action taken by the RP makes no actual difference.  We shouldn't try to enforce distinctions that are unenforceable, and in many cases, not even meaningful.

Let's simplify in this manner and thereby make using the spec more straightforward and less confusing.  We should just be talking about signed statements by issuers describing events that are responded to by recipients and leave it at that.

                                                       -- Mike

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 27 Mar 2017 02:00:43 -0500

Mike

A bit confused. In Buenos Aires I recall you had concerns about this being a new SOAP protocol and many other agreed. 

We agreed that jwts are assertions which are statements or claims by an issuer just as in saml or id tokens. 

Key distinguishing features:

* Independent action - receiver decides what to do
* Unidirectional - no error signaling is possible or desired since there is no command. The event is valid or not. 
* Can be statements of things that occurred recently or in the past (eg account compromised a week ago) 
* Delivery is fast and can be done at high rate. No need to wait for processing of event. 
* great for co-ordinating security subjects where state of each subject different or not fully known or cannot be known (can replace many rest commands by a client having to check state before updating)
* Is a compliment to REST by enabling a receiver to reconcile state and local policy to determine independent action. In some cases reconciliation can be done when needed with simple GET requests without resorting to polling.
* Can be processed asynchronously 
* Can be routed through a bus and other mechanisms (eg apns). 
* authority - the issuer may not have the authority to request changes of another party legally. 
* avoids status/state polling - constant checking for state changes at issuers (eg introspection). 
* loose coupling - we can interconnect security components without having a common information model about subjects or architectures or processes. 
* few attributes - turns out if receiver is deciding you usually don't need to say much. Most events we have discussed often only need a subject. 

Apologies if some bad wording or dups. Up late. 

Thanks,

Phil

Phil
> On Mar 26, 2017, at 11:34 PM, Mike Jones <[email-masked]> wrote:
> 
> One of the things that’s always bothered me about the SET spec is that it says:
> “Security Events are not commands issued between parties.  A security event is a statement of fact from the perspective of an issuer about the state of a security subject (e.g., a web resource, token, IP address, the issuer itself) that the issuer controls or is aware of, that has changed in some way (explicitly or implicitly).”
> Likewise, it includes “a SET reflects something that has already been processed and is historical in nature” and other similar statements.
>  
> Whether a SET is a historical statement of fact or a command has always seemed like a distinction without a difference in my mind.  I therefore propose that we strike that language from the SET spec because it’s not actionable or testable.  For instance, whether a logout token is the statement “I the OP have logged out the end-user whose session identifier at your RP is abc123” with a resulting action taken by the RP to log out that session or whether the logout token is the command “Please logout the end-user whose session identifier at your RP is abc123” with the same action taken by the RP makes no actual difference.  We shouldn’t try to enforce distinctions that are unenforceable, and in many cases, not even meaningful.
>  
> Let’s simplify in this manner and thereby make using the spec more straightforward and less confusing.  We should just be talking about signed statements by issuers describing events that are responded to by recipients and leave it at that.
>  
>                                                        -- Mike
>  
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Oiq2bVorawb7qyxeNY9tW2OTkG-JMGC7zxZGnUB1W1w&s=Rn3ixCMBFJP4XnvV5K_pLX0Xs8ArlleD1vQ-LnBhFDk&e=

---

From: Mike Jones <[email-masked]>
Date: Mon, 27 Mar 2017 10:55:56 +0000

The problem I have is that in a mathematical sense, for every command
              “do X”
there is an equivalent historical statement of fact
              “the time has come to do X”.

Therefore, the requirement “Security Events are not commands” is meaningless.

I should have been clearer that I’m fine with this part of the statement:
“A security event is a statement of fact from the perspective of an issuer about the state of a security subject (e.g., a web resource, token, IP address, the issuer itself) that the issuer controls or is aware of, that has changed in some way (explicitly or implicitly).”

It’s this part, which asserts in a logical fallacy, that I believe must go:
“Security Events are not commands issued between parties.”

Other related statements that also assert the fallacy should be similarly corrected.

I agree with all the goals that you’re asserting below, Phil.  Removing illogical statements about commands won’t change whether we achieve any of them.

                                                       Thanks,
                                                       -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked]]
Sent: Monday, March 27, 2017 2:01 AM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: Re: [Id-event] Statement of historical fact, command, or distinction without a difference?

Mike

Thanks,

Phil

Phil
On Mar 26, 2017, at 11:34 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
One of the things that’s always bothered me about the SET spec is that it says:
“Security Events are not commands issued between parties.  A security event is a statement of fact from the perspective of an issuer about the state of a security subject (e.g., a web resource, token, IP address, the issuer itself) that the issuer controls or is aware of, that has changed in some way (explicitly or implicitly).”
Likewise, it includes “a SET reflects something that has already been processed and is historical in nature” and other similar statements.

                                                       -- Mike

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Oiq2bVorawb7qyxeNY9tW2OTkG-JMGC7zxZGnUB1W1w&s=Rn3ixCMBFJP4XnvV5K_pLX0Xs8ArlleD1vQ-LnBhFDk&e=

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 27 Mar 2017 08:28:13 -0500

Events are signals. 

The effects of signals may be obvious but not always. 

Rfc7009 enables an actor to request token revocation at as AS. A token revocation event informs a downstream relying party a token WAS revoked by the issuer. It is historical. 

Another example suspicious activity is a statement by an issuer. As a signal it is up to the receiver to infer meaning. The process by which a signal becomes an action is totally up to the receiver. 

If you open the door to commands you complicate the specification dramatically. Commands imply compliance and errors. It reverses the intended semantics. 

Phil

> On Mar 27, 2017, at 5:55 AM, Mike Jones <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 27 Mar 2017 08:31:21 -0500

On 27 Mar 2017, at 08:28, Phil Hunt (IDM) <[email-masked]> wrote:
> 
> Commands imply compliance and errors.

In other words, for an event the recipient doesn’t get to say no.
For a command, it may, and the command source has to deal with that.

(Otherwise, the semantics are indeed rather dual.)

Grüße, Carsten

---

From: Mike Jones <[email-masked]>
Date: Mon, 27 Mar 2017 13:52:21 +0000

Commands can be expressed as historical statements of fact.  Saying that they can't be is false and will confuse people.  All I'm asking us to do is to remove the self-contradictory statement from the spec.  Asserting something that is logically false isn't something we should have anything to do with.

I said nothing about adding error handling, etc.  I would oppose that, as unneeded complexity.

				Thanks,
				-- Mike

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Monday, March 27, 2017 8:31 AM
To: Phil Hunt (IDM) <[email-masked]>
Cc: Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [Id-event] Statement of historical fact, command, or distinction without a difference?

Grüße, Carsten

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 27 Mar 2017 08:59:47 -0500

I would adjust that. 

The issuer does not require the receiver to take an action. 

The receiver has no obligation to state its actions to the issuer.  So the receiver can choose no, it is just not obliged to say so. 

We have talked about multi-step signal scenarios as well (hopefully these examples help)...

For example. RP issues suspicious activity event to IDP. IDP makes a note but makes no visible changes (note that by taking note it has actually made a change in state of the subject). 

A subsequent event from another RP causes the IDP to lock the subject account and to revoke all current sessions. The iDP sends logout events to all associated RPs for the subject. 

So in this scenario, none of the events look like commands. They are signals that receivers interpret in their own context. 

Phil

> On Mar 27, 2017, at 8:31 AM, Carsten Bormann <[email-masked]> wrote:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=v6BZ1TmwwvOCFhtrnamBdm4I1nb6ljGFW7SdmaC0_LU&s=K3RPpG88rxjx4rdMPe3xG2-J49aynEOTTXCoK4SxKHw&e=

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 27 Mar 2017 16:23:10 +0200

Hello,

Facts cannot be disputed (but typically can be enriched), the 
information emitted as an event might contradict the information emitted 
by another event. It is vital to understand that this kind of 
information is a statement and not a fact. If facts conflict, in almost 
ever case they are not facts in the first place. It might be a tiny 
distinction, it might not be very relevant distinction in all domains of 
application, but dropping that distinction changes the confidence a 
consumer about the integrity and guarantees assassinated with an event, 
significantly.

E.g. multiple different sources of the same kind of information (data 
provenance) are typically an indicator that the information conveyed is 
a statement.
Facts cannot be disputed (but typically can be enriched), the 
information emitted as an event might contradict the information emitted 
by another event. It is vital to understand that this kind of 
information is a statement and not a fact. If facts conflict, in almost 
ever case they are not facts in the first place. It might be a tiny 
distinction, it might not be very relevant in all domains of 
application, but dropping that distinction changes the confidence a 
consumer can put in the integrity and guarantees assassinated with an 
event, significantly.

E.g. multiple different sources of the same kind of information (data 
provenance) are typically an indicator that the information conveyed is 
a statement.

Viele Grüße,

Henk

>> “Security Events are not commands issued between parties.  A security
>> event is a statement of fact from the perspective of an issuer about
>> the state of a security subject (e.g., a web resource, token, IP
>> address, the issuer itself) that the issuer controls or is aware of,
>> that has changed in some way (explicitly or implicitly).”
>> Likewise, it includes “a SET reflects something that has already been
>> processed and is historical in nature” and other similar statements.
>>
>> Whether a SET is a historical statement of fact or a command has
>> always seemed like a distinction without a difference in my mind.  I
>> therefore propose that we strike that language from the SET spec
>> because *it’s not actionable or testable*.  For instance, whether a
>> logout token is the statement “I the OP have logged out the end-user
>> whose session identifier at your RP is abc123” with a resulting action
>> taken by the RP to log out that session or whether the logout token is
>> the command “Please logout the end-user whose session identifier at
>> your RP is abc123” with the same action taken by the RP makes no
>> actual difference.  We shouldn’t try to enforce distinctions that are
>> unenforceable, and in many cases, not even meaningful.
>>
>> Let’s simplify in this manner and thereby make using the spec more
>> straightforward and less confusing.  We should just be talking about
>> signed statements by issuers describing events that are responded to
>> by recipients and leave it at that.
>>
>>                                                        -- Mike
>>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/id-event

---

From: Mike Jones <[email-masked]>
Date: Mon, 27 Mar 2017 14:26:39 +0000

You raise a good point.  We should be talking about Claims (which is standard JWT terminology), rather than facts, for exactly the reasons you state.

				-- Mike

-----Original Message-----
From: Id-event [mailto:[email-masked]] On Behalf Of Henk Birkholz
Sent: Monday, March 27, 2017 9:23 AM
To: [email-masked]
Subject: Re: [Id-event] Statement of historical fact, command, or distinction without a difference?

Hello,

Facts cannot be disputed (but typically can be enriched), the information emitted as an event might contradict the information emitted by another event. It is vital to understand that this kind of information is a statement and not a fact. If facts conflict, in almost ever case they are not facts in the first place. It might be a tiny distinction, it might not be very relevant distinction in all domains of application, but dropping that distinction changes the confidence a consumer about the integrity and guarantees assassinated with an event, significantly.

E.g. multiple different sources of the same kind of information (data
provenance) are typically an indicator that the information conveyed is a statement.
Facts cannot be disputed (but typically can be enriched), the information emitted as an event might contradict the information emitted by another event. It is vital to understand that this kind of information is a statement and not a fact. If facts conflict, in almost ever case they are not facts in the first place. It might be a tiny distinction, it might not be very relevant in all domains of application, but dropping that distinction changes the confidence a consumer can put in the integrity and guarantees assassinated with an event, significantly.

E.g. multiple different sources of the same kind of information (data
provenance) are typically an indicator that the information conveyed is a statement.

Viele Grüße,

Henk

>> whose session identifier at your RP is abc123” with a resulting 
>> action taken by the RP to log out that session or whether the logout 
>> token is the command “Please logout the end-user whose session 
>> identifier at your RP is abc123” with the same action taken by the RP 
>> makes no actual difference.  We shouldn’t try to enforce distinctions 
>> that are unenforceable, and in many cases, not even meaningful.
>>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 27 Mar 2017 11:12:42 -0500

Mike,

Can you add this question to the issues part our WG discussion on the SET draft?  (in addition to JWT vs. SET, and issuer disambiguation)

I feel that the sentence or something like it is critical to keep profiling drafts from venturing into commands and the ensuring complications that implies.  My goal is to make sure SETs stay simple.

It may be useful to re-work the draft to clarify that events are used by receivers “signals” rather than saying that events are not commands.

I am ok with claims terminology since the recipient is free to judge the veracity of the statements and decides on their meaning.

Phil

Oracle Corporation, Identity Cloud Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Mar 27, 2017, at 9:26 AM, Mike Jones <[email-masked]> wrote:
> 
> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Henk Birkholz
> To: [email-masked] <mailto:[email-masked]>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=dWceJsADa4_hGGy241PsoZI-Dxds9P2vsU8C71zqHbI&s=HHc_0EPTFQvAmgjzVRvPnaUxZK-fZzTpzeCF3CbRCXk&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=dWceJsADa4_hGGy241PsoZI-Dxds9P2vsU8C71zqHbI&s=HHc_0EPTFQvAmgjzVRvPnaUxZK-fZzTpzeCF3CbRCXk&e=> 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=dWceJsADa4_hGGy241PsoZI-Dxds9P2vsU8C71zqHbI&s=HHc_0EPTFQvAmgjzVRvPnaUxZK-fZzTpzeCF3CbRCXk&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=dWceJsADa4_hGGy241PsoZI-Dxds9P2vsU8C71zqHbI&s=HHc_0EPTFQvAmgjzVRvPnaUxZK-fZzTpzeCF3CbRCXk&e=> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=dWceJsADa4_hGGy241PsoZI-Dxds9P2vsU8C71zqHbI&s=HHc_0EPTFQvAmgjzVRvPnaUxZK-fZzTpzeCF3CbRCXk&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=dWceJsADa4_hGGy241PsoZI-Dxds9P2vsU8C71zqHbI&s=HHc_0EPTFQvAmgjzVRvPnaUxZK-fZzTpzeCF3CbRCXk&e=>

---

From: Mike Jones <[email-masked]>
Date: Mon, 27 Mar 2017 16:31:59 +0000

Sure.  Already in my working issues list. ;-)

I think I’m actually OK with a statement of intent, something like this:
“A security event is a set of claims made by an issuer about the state of a security subject (e.g., a web resource, token, IP address, the issuer itself) that the issuer controls or is aware of, that has changed in some way (explicitly or implicitly); it is intended to be used to represent assertions about state that recipients will react to, rather than to represent a command to recipients.”
That’s far better than starting with the current statement “Security Events are not commands issued between parties”.  The current wording leads to slippery slope arguments about what is and isn’t a command that are mathematically undecidable.

                                                       -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Monday, March 27, 2017 11:13 AM
To: Mike Jones <[email-masked]>
Cc: Henk Birkholz <[email-masked]>; [email-masked]
Subject: Re: [Id-event] Statement of historical fact, command, or distinction without a difference?

Mike,

Phil

Oracle Corporation, Identity Cloud Architect & Standards
@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On Mar 27, 2017, at 9:26 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                        -- Mike

-----Original Message-----
From: Id-event [mailto:[email-masked]] On Behalf Of Henk Birkholz
Sent: Monday, March 27, 2017 9:23 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Id-event] Statement of historical fact, command, or distinction without a difference?

Hello,

Viele Grüße,

Henk

One of the things that’s always bothered me about the SET spec is
that it says:

                                                      -- Mike

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=dWceJsADa4_hGGy241PsoZI-Dxds9P2vsU8C71zqHbI&s=HHc_0EPTFQvAmgjzVRvPnaUxZK-fZzTpzeCF3CbRCXk&e=

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=dWceJsADa4_hGGy241PsoZI-Dxds9P2vsU8C71zqHbI&s=HHc_0EPTFQvAmgjzVRvPnaUxZK-fZzTpzeCF3CbRCXk&e=
_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=dWceJsADa4_hGGy241PsoZI-Dxds9P2vsU8C71zqHbI&s=HHc_0EPTFQvAmgjzVRvPnaUxZK-fZzTpzeCF3CbRCXk&e=

---

From: Phil Hunt <[email-masked]>
Date: Mon, 27 Mar 2017 11:35:17 -0500

I like the new text. Thanks Mike.  Let’s still talk about it. I think others may have questions about this.

Phil

> On Mar 27, 2017, at 11:31 AM, Mike Jones <[email-masked]> wrote:
> 
>   <>
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=J0kWVjpr9EtSCkFBmNldC2PCl-yeLOGL9-jD625Nv_s&s=4j4rjt5ICjibtcn5ajo8YLbtnB4lHCehzozs5faiMjA&e=>
> [email-masked] <mailto:[email-masked]>
>  
>  
>  
>  
>  
>  
>  
>  
>  
> 
>  
> On Mar 27, 2017, at 9:26 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>  
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 28 Mar 2017 09:20:18 -0500

I fully agree with the sentiment that we don’t want to present SET as a command and control protocol, but I’m also sensitive to Mike’s concern that we’re making statements in the spec that can’t be enforced in a meaningful way. We should say something that cements a SET as an *event* description, and be clear that receipt of an event may or may not cause an action on the part of the receiver, but that the issuer of the event has zero control over or insight into the recipient’s behavior. These events are meant to inform, not control. You may recall that Sarah’s early proposal for naming this was JWL — JSON Web Log — and this may be where some of the “it’s a historical thing” language grew out of. But instead of focusing on saying what terms a SET is or is not, we should focus on what it *does* and what it *means*. So a SET describes an event about a party in a format that is meant to be carried between different parties who would like to know about, and potentially act on, knowledge of that event. 

I think Mike’s new text is a good start on this path, though it’s not quite there yet and we should continue to work on it. I’ll admit that I haven’t given the latest draft a thorough read, mostly sticking to the syntax and representation bits, but I think this type of situating is a good topic for tomorrow’s meeting in Chicago.

 — Justin

> On Mar 27, 2017, at 11:35 AM, Phil Hunt <[email-masked]> wrote:
> 
>> On Mar 27, 2017, at 11:31 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: Phil Hunt [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
>> Cc: Henk Birkholz <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>