Subject: Re: [Id-event] SecEvent consensus calls

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Sat, 6 Jan 2018 00:07:55 +0000

Now that the holidays are over I have some time to reply to this and add some additional context for those who were not a part of the discussion Mike referred to.

One of the first things that became clear in the discussion was that there was disagreement over the answer to Yaron’s third question, “what are our interoperability expectations [for SET]?” My expectation, assuming a SET format that permits multiple event types within a single token, is that any two arbitrary event types should be combinable. This is why I have argued strongly for clarifying the semantics of multi-part SETs; you can’t combine two event types if they disagree about what it means when you combine event types. Without that compatibility, we’re left with defining an “events” JWT claim and precious little more, and if that’s the case then I have to ask why it takes 8,000 words to do that.

My expectation is based off of use cases and examples presented by members of the working group. Putting my RISC hat on, I don’t see use cases there for multi-part SETs, and am happy to have the discussion within RISC over whether or not we mandate single-event SETs in our profile. My only concern is that the spec accurately expresses the consequences and resulting consequences of whatever consensus we reach. If the consensus is that individual profiles should be able to define what it means when two event types are in the same SET, then the SET spec should make that clear: avoid any and all statements about the meaning of a multi-part SET (such as the language in section 2 of the current draft), call out defining this as a responsibility of profiling specs, and note the compatibility implications. If the consensus is that profiles should not be able to define this, then we need to actually define it in the SET spec.

I’d very much like to hear from others in the working group their thoughts on Yaron’s three questions – the last one in particular as I think everything else falls out from that.

--
Annabelle Richard Backman
Amazon – Identity Services

From: Id-event <[email-masked]> on behalf of Mike Jones <[email-masked]>
Date: Friday, December 22, 2017 at 4:40 PM
To: Yaron Sheffer <[email-masked]>, SecEvent <[email-masked]>
Subject: Re: [Id-event] SecEvent consensus calls

On Wednesday there was an informal discussion among Annabelle, Marius, Phil, Morteza, myself, and a few others about trying to find a good path forward for SET.

I opened by asking if people would be happy with us adding language along the lines that Yaron had proposed saying that profiles can restrict the “events” list to a single value.  Annabelle said that that would be OK but wouldn’t solve the whole problem.  Annabelle said that to solve the whole problem, the spec would have to become clear that it’s up to profiles to define what the relationship is among multiple “events” elements when they occur, and indeed, whether they are permitted to occur.  I think that all agreed that clarity on this point is needed for users of the spec.

Annabelle thought that Yaron’s third question “What are our interoperability expectations?” was a great one and said that my answer helped clarify what was and was not intended to be able to be interoperable with and without profile knowledge.  This was another point where I think we all agreed that being super-clear in the spec on this point would be good for developers and profile designers.

Phil made the point that if there are multiple elements in the “events” list, they are there because they convey related aspects of a single logical event and because the profile called for this.  An example used in the discussion (which I believe came from Marius) was that “logout”, “session cancelled”, and “account suspended” information could be aspects conveyed of a single logical event residing in a single SET.  Conversely, the “events” set is not to be used for aggregating unrelated information.  I think there was agreement on these points as well.

As a result of these positive discussions, I agreed to review the current SET draft and propose any appropriate changes to make sure the points above are super clear to others.  Annabelle, Phil, and Morteza also expressed an interest in doing this and reviewing the proposed clarifications.

Finally, I also stated that I would be thrilled to work on a new event subject spec with Annabelle and others wishing to do so and that some of the subject language in Annabelle’s draft is almost certainly applicable.  I would work with others to try to get this to happen fast, as RISC, which I care deeply about, needs it.  Marius also stressed that it was important for this to happen in a timely fashion.

To Yaron’s point about wanting more examples, I’ve also asked Marius and Adam for a RISC example or two to include in the working group specification.

Hopefully these actions will help get us to a place where we can all agree that we reached the IETF definition of rough consensus.  Thanks all who were there for the positive and productive discussions on Wednesday.

                                                                -- Mike

From: Mike Jones
Sent: Wednesday, December 20, 2017 8:54 AM
To: Yaron Sheffer <[email-masked]>; SecEvent <[email-masked]>
Subject: RE: [Id-event] SecEvent consensus calls

Thanks, Yaron.  Replies are inline prefixed by “Mike>”.

From: Id-event [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Wednesday, December 20, 2017 8:19 AM
To: SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: [Id-event] SecEvent consensus calls

Dear SecEvent participants,

First, I would like to thank all those who shared their opinions on the list and worked to clarify the issues at stake for the benefit of all of us.

Three issues were discussed:

1. The syntax and semantics of the "events" claim, whether multiple events can be expressed, logical events vs. aspects of events etc.
2. Whether we want to define a standard "subject" claim within the event object.
3. Whether we want to predefine a number of subject types.

The bulk of the discussion was about issue #1, and in my opinion, if we untangle this issue, it would be much easier to reach consensus on #2 and #3. Unfortunately, in my opinion, we have not reached (the IETF definition of) rough consensus on #1. While the majority of participants expressed the opinion that we should keep the current text as-is, a non-negligible minority had a detailed alternative text and a number of significant implementation-based concerns with the current text.

We cannot move forward without rough consensus, but clearly we all want to publish a SET RFC as soon as we can, to enable multiple profiles to be developed by other organizations. So if we want to get to an RFC as a group, we need to continue this discussion until we do reach technical consensus. I would like to give this discussion the remaining days of the year (until EOB on Dec. 31). If we have not reached consensus by then, Dick and I will ask Kathleen to decide on the next steps for this WG.

To lead into this discussion, I would like to raise some points that the discussion did not clarify to me:

- What is the value of a SET, in addition to its being "a kind of JWT". Specifically, let's assume a software architecture that consists of three layers: SET profile-specific library, generic SET processor, generic JWT library. What would be the functionality (or the added value) of the middle layer?
Mike> The value of a SET is providing an authenticated standard representation of information about an event that occurred.  It defines an “events” JWT claim to represent this information.  I actually think that many use cases *will not* use a generic SET processor – just like a lot of use cases don’t develop a generic processor for other JWT claims.  Yes, a generic JWT library will often be used, but for simple event use cases, I suspect that the “events” claim will be directly processed by the application, without the use of additional middleware.

- What are the existing implementations that prevent change to the current spec, even changes as trivial as renaming "events" to "event"? Are there any production or near-production implementations in addition to the OIDC Back Channel Logout (which is arguably a trivial use of SET)? From an IETF process point of view, I'd like to point out that any I-D is completely open to changes until actual publication as an RFC, and certainly until it is delivered to the IESG.
Mike> There are a number of implementations of OpenID Connect Back-Channel Logout that are compatible with the working group draft.  This specification has reached the Implementer’s Draft stage.  Strictly speaking, it intentionally did not take a dependency on SET exactly because it might change.  Should a breaking change occur in SET, the OpenID Connect working group will have to decide wither to track that change or stay with the syntax it is already using.

Mike> If the proposed alternative syntax were simpler for most use cases than the existing one, I might be open to it, but it reintroduces a distinction between primary and secondary events that the working group long ago decided against. It introduces very complicated and deeply nested “related events” and “extensions” syntax – none of which is needed in the working group draft.  We should stay with what’s simple and what already works well.

- What are our interoperability expectations? One of the participants mentioned that his company will only send single events and will "prefer" to receive single events. Can such an implementation be interoperable with all RFC compliant implementations? If we leave too much of the SET semantics for profiles to define, are we sacrificing interoperability?
Mike> My interoperability expectations are that profiles will define the syntax and semantics of particular SETs and implementations of those profiles will be interoperable with one another.  It’s up to the profiles to define whether events must use only a single URI to convey a single aspect of the event or whether multiple URIs are allowed.  Indeed, this was your very suggestion in https://www.ietf.org/mail-archive/web/id-event/current/msg00736.html Yaron.  I’m fine with adding text along those lines.  Hopefully clarifying that profiles can dictate that the “events” set must be a singleton will help provide those who want this restriction more comfort with the working group specification.

Mike> This is exactly parallel to the interoperability expectations for JWTs.  Particular JWT profiles will have interoperable implementations but there is no expectation that unrelated JWT profiles will interoperate, other than that they use the same cryptographic formats.  An ID Token is not the same as a caller-ID record, and that’s just fine.

Lastly, I must say that both the WG draft and the alternative draft woefully lack worked out examples of concrete events ("logout", "email change" etc.), which would have clarified the similarities and differences between the drafts and might have made this discussion easier and shorter.

Mike> Figure 1 in https://tools.ietf.org/html/draft-ietf-secevent-token-03#section-2 is a SCIM password reset example.  Figure 2 is a logout event example.  Figure 3 is an example consent event.  Figure 4 is a SCIM create event example.  That said, I’m fine adding more examples, for instance, a RISC example or two.

Thanks,
    Yaron

                                                       Thanks,
                                                       -- Mike

---

From: Mike Jones <[email-masked]>
Date: Sat, 6 Jan 2018 01:37:16 +0000

As promised, I’ve created proposed edits to the working group specification that clarifies the points described earlier in this thread.  This includes clearly specifying the responsibilities of profiling specifications with respect to multiple “events” values, as was requested by Annabelle both at Cisco and in her note just now.  The proposed changes both update the Section 2 (The Security Event Token (SET)) text referred to by Annabelle and add a new paragraph to Section 3 (Requirements for SET Profiles) explicitly defining the responsibilities of Profiling Specifications for defining how and when multiple "events" values are (or are not) used.  The text for some of the claims definitions was also adjusted to be unambiguous with respect to these responsibilities.

The new profile requirements text is:
Among the syntax and semantics of SETs that Profiling Specifications define is whether and how multiple events values are used for SETs conforming to those profiles. Many valid choices are possible. For instance, some profiles might allow multiple event identifiers to be present and specify that any that are not understood by recipients be ignored, thus enabling extensibility. Other profiles might allow multiple event identifiers to be present but require that all be understood if the SET is to be accepted. Some profiles might require that only a single value be present. All such choices are within the scope of Profiling Specifications to define.

Hopefully the incorporation of the proposed changes that significantly clarify roles and responsibilities will provide us a basis to finally finish the SET spec soon.  Your feedback is welcomed.

I’ve created a PR to enable other editors and WG members to review the proposed changes before they are merged: https://github.com/independentid/Identity-Events/pull/9.  A summary of the changes made (as found in the changelog) is:
·         Clarified that all "events" values must represent aspects of the same state change that occurred to the subject -- not an aggregation of unrelated events about the subject.
·         Removed ambiguities about the roles of multiple "events" values and the responsibilities of profiling specifications for defining how and when they are used.
·         Corrected places where the term JWT was used when what was actually being discussed was the JWT Claims Set.
·         Addressed terminology inconsistencies. In particular, standardized on using the term "issuer" to align with JWT terminology and the "iss" claim. Previously the term "transmitter" was sometimes used and "issuer" was sometimes used. Likewise, standardized on using the term "recipient" instead of "receiver" for the same reasons.
·         Applied numerous grammar, syntax, and formatting corrections.
I’ve also attached rendered versions, if you prefer to read the updated text in context.

Have a good weekend, everyone!

                                                                Best wishes,
                                                                -- Mike

From: Richard Backman, Annabelle [mailto:[email-masked]]
Sent: Friday, January 5, 2018 4:08 PM
To: Mike Jones <[email-masked]>; Yaron Sheffer <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] SecEvent consensus calls

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Mike Jones <[email-masked]<mailto:[email-masked]>>
Date: Friday, December 22, 2017 at 4:40 PM
To: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] SecEvent consensus calls

                                                                -- Mike

From: Mike Jones
Sent: Wednesday, December 20, 2017 8:54 AM
To: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Id-event] SecEvent consensus calls

Thanks,
    Yaron

                                                       Thanks,
                                                       -- Mike

---

From: Mike Jones <[email-masked]>
Date: Mon, 8 Jan 2018 22:14:59 +0000

I added a RISC event example to the pull request<https://github.com/independentid/Identity-Events/pull/9> with this commit https://github.com/independentid/Identity-Events/pull/9/commits/26c6c49f8c4f6f8bd8117ba005dabcb200f18919.  Thanks to Marius and Adam for providing the RISC information.

                                                                -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, January 5, 2018 5:37 PM
To: Richard Backman, Annabelle <[email-masked]>; Yaron Sheffer <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] SecEvent consensus calls

                                                                Best wishes,
                                                                -- Mike

From: Richard Backman, Annabelle [mailto:[email-masked]]
Sent: Friday, January 5, 2018 4:08 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] SecEvent consensus calls

                                                                -- Mike

From: Mike Jones

Thanks,
    Yaron

                                                       Thanks,
                                                       -- Mike

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 8 Jan 2018 14:21:04 -0800

Thanks Mike.

As a general note, please keep in mind that the RISC profile is work in
progress. Most likely the subject will not be identified with top level
iss+sub but rather with a nested composite claim.

Mike, can we send a pull request with adjustments alter on once the RISC
profile gets updated?

Marius

On Mon, Jan 8, 2018 at 2:14 PM, Mike Jones <[email-masked]>
wrote:

> I added a RISC event example to the pull request
> <https://github.com/independentid/Identity-Events/pull/9> with this
> commit https://github.com/independentid/Identity-Events/pull/9/commits/
> 26c6c49f8c4f6f8bd8117ba005dabcb200f18919.  Thanks to Marius and Adam for
> providing the RISC information.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Id-event [mailto:[email-masked]] *On Behalf Of *Mike
> Jones
> *Sent:* Friday, January 5, 2018 5:37 PM
> *To:* Richard Backman, Annabelle <[email-masked]>; Yaron Sheffer <
> [email-masked]>; SecEvent <[email-masked]>
> *Subject:* Re: [Id-event] SecEvent consensus calls
>
>
>
> As promised, I’ve created proposed edits to the working group
> specification that clarifies the points described earlier in this thread.
> This includes clearly specifying the responsibilities of profiling
> specifications with respect to multiple “events” values, as was requested
> by Annabelle both at Cisco and in her note just now.  The proposed changes
> both update the Section 2 (The Security Event Token (SET)) text referred to
> by Annabelle and add a new paragraph to Section 3 (Requirements for SET
> Profiles) explicitly defining the responsibilities of Profiling
> Specifications for defining how and when multiple "events" values are (or
> are not) used.  The text for some of the claims definitions was also
> adjusted to be unambiguous with respect to these responsibilities.
>
>
>
> Among the syntax and semantics of SETs that Profiling Specifications
> define is whether and how multiple events values are used for SETs
> conforming to those profiles. Many valid choices are possible. For
> instance, some profiles might allow multiple event identifiers to be
> present and specify that any that are not understood by recipients be
> ignored, thus enabling extensibility. Other profiles might allow multiple
> event identifiers to be present but require that all be understood if the
> SET is to be accepted. Some profiles might require that only a single value
> be present. All such choices are within the scope of Profiling
> Specifications to define.
>
>
>
> Hopefully the incorporation of the proposed changes that significantly
> clarify roles and responsibilities will provide us a basis to finally
> finish the SET spec soon.  Your feedback is welcomed.
>
>
>
> I’ve created a PR to enable other editors and WG members to review the
> proposed changes before they are merged: https://github.com/
> independentid/Identity-Events/pull/9.  A summary of the changes made (as
> found in the changelog) is:
>
> ·         Clarified that all "events" values must represent aspects of
> the same state change that occurred to the subject -- not an aggregation of
> unrelated events about the subject.
>
> ·         Removed ambiguities about the roles of multiple "events" values
> and the responsibilities of profiling specifications for defining how and
> when they are used.
>
> ·         Corrected places where the term JWT was used when what was
> actually being discussed was the JWT Claims Set.
>
> ·         Addressed terminology inconsistencies. In particular,
> standardized on using the term "issuer" to align with JWT terminology and
> the "iss" claim. Previously the term "transmitter" was sometimes used and
> "issuer" was sometimes used. Likewise, standardized on using the term
> "recipient" instead of "receiver" for the same reasons.
>
>                                                                 Best
> wishes,
> *From:* Richard Backman, Annabelle [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Friday, January 5, 2018 4:08 PM
> *To:* Mike Jones <[email-masked]>; Yaron Sheffer <
> [email-masked]>; SecEvent <[email-masked]>
>
> *Subject:* Re: [Id-event] SecEvent consensus calls
>
>
>
> Now that the holidays are over I have some time to reply to this and add
> some additional context for those who were not a part of the discussion
> Mike referred to.
>
>
>
> One of the first things that became clear in the discussion was that there
> was disagreement over the answer to Yaron’s third question, “what are our
> interoperability expectations [for SET]?” My expectation, assuming a SET
> format that permits multiple event types within a single token, is that any
> two arbitrary event types should be combinable. This is why I have argued
> strongly for clarifying the semantics of multi-part SETs; you can’t combine
> two event types if they disagree about what it means when you combine event
> types. Without that compatibility, we’re left with defining an “events” JWT
> claim and precious little more, and if that’s the case then I have to ask
> why it takes 8,000 words to do that.
>
>
>
> My expectation is based off of use cases and examples presented by members
> of the working group. Putting my RISC hat on, I don’t see use cases there
> for multi-part SETs, and am happy to have the discussion within RISC over
> whether or not we mandate single-event SETs in our profile. My only concern
> is that the spec accurately expresses the consequences and resulting
> consequences of whatever consensus we reach. If the consensus is that
> individual profiles should be able to define what it means when two event
> types are in the same SET, then the SET spec should make that clear: avoid
> any and all statements about the meaning of a multi-part SET (such as the
> language in section 2 of the current draft), call out defining this as a
> responsibility of profiling specs, and note the compatibility implications.
> If the consensus is that profiles should not be able to define this, then
> we need to actually define it in the SET spec.
>
>
>
> I’d very much like to hear from others in the working group their thoughts
> on Yaron’s three questions – the last one in particular as I think
> everything else falls out from that.
>
>
>
>
>
>
> --
>
> *From: *Id-event <[email-masked]> on behalf of Mike Jones <
> [email-masked]>
> *Date: *Friday, December 22, 2017 at 4:40 PM
> *To: *Yaron Sheffer <[email-masked]>, SecEvent <[email-masked]>
> *Subject: *Re: [Id-event] SecEvent consensus calls
>
>
>
> On Wednesday there was an informal discussion among Annabelle, Marius,
> Phil, Morteza, myself, and a few others about trying to find a good path
> forward for SET.
>
>
>
> I opened by asking if people would be happy with us adding language along
> the lines that Yaron had proposed saying that profiles can restrict the
> “events” list to a single value.  Annabelle said that that would be OK but
> wouldn’t solve the whole problem.  Annabelle said that to solve the whole
> problem, the spec would have to become clear that it’s up to profiles to
> define what the relationship is among multiple “events” elements when they
> occur, and indeed, whether they are permitted to occur.  I think that all
> agreed that clarity on this point is needed for users of the spec.
>
>
>
> Annabelle thought that Yaron’s third question “What are our
> interoperability expectations?” was a great one and said that my answer
> helped clarify what was and was not intended to be able to be interoperable
> with and without profile knowledge.  This was another point where I think
> we all agreed that being super-clear in the spec on this point would be
> good for developers and profile designers.
>
>
>
> Phil made the point that if there are multiple elements in the “events”
> list, they are there because they convey related aspects of a single
> logical event and because the profile called for this.  An example used in
> the discussion (which I believe came from Marius) was that “logout”,
> “session cancelled”, and “account suspended” information could be aspects
> conveyed of a single logical event residing in a single SET.  Conversely,
> the “events” set is not to be used for aggregating unrelated information.
> I think there was agreement on these points as well.
>
>
>
> As a result of these positive discussions, I agreed to review the current
> SET draft and propose any appropriate changes to make sure the points above
> are super clear to others.  Annabelle, Phil, and Morteza also expressed an
> interest in doing this and reviewing the proposed clarifications.
>
>
>
> Finally, I also stated that I would be thrilled to work on a new event
> subject spec with Annabelle and others wishing to do so and that some of
> the subject language in Annabelle’s draft is almost certainly applicable.
> I would work with others to try to get this to happen fast, as RISC, which
> I care deeply about, needs it.  Marius also stressed that it was important
> for this to happen in a timely fashion.
>
>
>
> To Yaron’s point about wanting more examples, I’ve also asked Marius and
> Adam for a RISC example or two to include in the working group
> specification.
>
>
>
> Hopefully these actions will help get us to a place where we can all agree
> that we reached the IETF definition of rough consensus.  Thanks all who
> were there for the positive and productive discussions on Wednesday.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Mike Jones
> *Sent:* Wednesday, December 20, 2017 8:54 AM
> *To:* Yaron Sheffer <[email-masked]>; SecEvent <[email-masked]>
> *Subject:* RE: [Id-event] SecEvent consensus calls
>
>
>
> *From:* Id-event [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Yaron Sheffer
> *Sent:* Wednesday, December 20, 2017 8:19 AM
> *To:* SecEvent <[email-masked]>
> *Subject:* [Id-event] SecEvent consensus calls
>
>
>
> First, I would like to thank all those who shared their opinions on the
> list and worked to clarify the issues at stake for the benefit of all of us.
>
> 1. The syntax and semantics of the "events" claim, whether multiple events
> can be expressed, logical events vs. aspects of events etc.
> The bulk of the discussion was about issue #1, and in my opinion, if we
> untangle this issue, it would be much easier to reach consensus on #2 and
> #3. Unfortunately, in my opinion, we have not reached (the IETF definition
> of) rough consensus on #1. While the majority of participants expressed the
> opinion that we should keep the current text as-is, a non-negligible
> minority had a detailed alternative text and a number of significant
> implementation-based concerns with the current text.
>
> We cannot move forward without rough consensus, but clearly we all want to
> publish a SET RFC as soon as we can, to enable multiple profiles to be
> developed by other organizations. So if we want to get to an RFC as a
> group, we need to continue this discussion until we do reach technical
> consensus. I would like to give this discussion the remaining days of the
> year (until EOB on Dec. 31). If we have not reached consensus by then, Dick
> and I will ask Kathleen to decide on the next steps for this WG.
>
> - What is the value of a SET, in addition to its being "a kind of JWT".
> Specifically, let's assume a software architecture that consists of three
> layers: SET profile-specific library, generic SET processor, generic JWT
> library. What would be the functionality (or the added value) of the middle
> layer?
>
> Mike> The value of a SET is providing an authenticated standard
> representation of information about an event that occurred.  It defines an
> “events” JWT claim to represent this information.  I actually think that
> many use cases **will not** use a generic SET processor – just like a lot
> of use cases don’t develop a generic processor for other JWT claims.  Yes,
> a generic JWT library will often be used, but for simple event use cases, I
> suspect that the “events” claim will be directly processed by the
> application, without the use of additional middleware.
>
>
> - What are the existing implementations that prevent change to the current
> spec, even changes as trivial as renaming "events" to "event"? Are there
> any production or near-production implementations in addition to the OIDC
> Back Channel Logout (which is arguably a trivial use of SET)? From an IETF
> process point of view, I'd like to point out that any I-D is completely
> open to changes until actual publication as an RFC, and certainly until it
> is delivered to the IESG.
>
> Mike> There are a number of implementations of OpenID Connect Back-Channel
> Logout that are compatible with the working group draft.  This
> specification has reached the Implementer’s Draft stage.  Strictly
> speaking, it intentionally did not take a dependency on SET exactly because
> it might change.  Should a breaking change occur in SET, the OpenID Connect
> working group will have to decide wither to track that change or stay with
> the syntax it is already using.
>
>
>
> Mike> If the proposed alternative syntax were simpler for most use cases
> than the existing one, I might be open to it, but it reintroduces a
> distinction between primary and secondary events that the working group
> long ago decided against. It introduces very complicated and deeply nested
> “related events” and “extensions” syntax – none of which is needed in the
> working group draft.  We should stay with what’s simple and what already
> works well.
>
>
> - What are our interoperability expectations? One of the participants
> mentioned that his company will only send single events and will "prefer"
> to receive single events. Can such an implementation be interoperable with
> all RFC compliant implementations? If we leave too much of the SET
> semantics for profiles to define, are we sacrificing interoperability?
>
> Mike> My interoperability expectations are that profiles will define the
> syntax and semantics of particular SETs and implementations of those
> profiles will be interoperable with one another.  It’s up to the profiles
> to define whether events must use only a single URI to convey a single
> aspect of the event or whether multiple URIs are allowed.  Indeed, this was
> your very suggestion in https://www.ietf.org/mail-
> archive/web/id-event/current/msg00736.html Yaron.  I’m fine with adding
> text along those lines.  Hopefully clarifying that profiles can dictate
> that the “events” set must be a singleton will help provide those who want
> this restriction more comfort with the working group specification.
>
>
>
> Mike> This is exactly parallel to the interoperability expectations for
> JWTs.  Particular JWT profiles will have interoperable implementations but
> there is no expectation that unrelated JWT profiles will interoperate,
> other than that they use the same cryptographic formats.  An ID Token is
> not the same as a caller-ID record, and that’s just fine.
>
>
> Lastly, I must say that both the WG draft and the alternative draft
> woefully lack worked out examples of concrete events ("logout", "email
> change" etc.), which would have clarified the similarities and differences
> between the drafts and might have made this discussion easier and shorter.
>
>
>
> Mike> Figure 1 in https://tools.ietf.org/html/
> draft-ietf-secevent-token-03#section-2 is a SCIM password reset example.
> Figure 2 is a logout event example.  Figure 3 is an example consent event.
> Figure 4 is a SCIM create event example.  That said, I’m fine adding more
> examples, for instance, a RISC example or two.
>
>
> Thanks,
>     Yaron
>
>
>
>                                                        Thanks,
>
>                                                        -- Mike
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 8 Jan 2018 14:50:24 -0800

I am ok with Mike's new changes.

Regarding keeping in sync with profiling specs (eg risc), AFAIK, once published only errata are doable.  Not sure if this type of update can be approached as errata. 

Because SET is a foundation spec, we have a chicken and the egg problem with examples. 

My thought was that all examples in SET are hypothetical and examples are not normative AND subject to change. Readers may need stronger reminding that specs like risc and scim are the official sources. There is some text to this effect already.  

Phil

> On Jan 8, 2018, at 2:21 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> Thanks Mike.
> 
> As a general note, please keep in mind that the RISC profile is work in progress. Most likely the subject will not be identified with top level iss+sub but rather with a nested composite claim.
> 
> Mike, can we send a pull request with adjustments alter on once the RISC profile gets updated?
> 
> Marius
> 
>> On Mon, Jan 8, 2018 at 2:14 PM, Mike Jones <[email-masked]> wrote:
>> I added a RISC event example to the pull request with this commit https://github.com/independentid/Identity-Events/pull/9/commits/26c6c49f8c4f6f8bd8117ba005dabcb200f18919.  Thanks to Marius and Adam for providing the RISC information.
>> 
>>  
>> 
>>                                                                 -- Mike
>> 
>>  
>> 
>> To: SecEvent <[email-masked]>
> _______________________________________________
> 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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=P1ygNibseS7ywo99BD5nfQZr507j8Ohd36N2rP7cu4A&e=

---

From: Mike Jones <[email-masked]>
Date: Mon, 8 Jan 2018 22:55:59 +0000

You’ll notice that the RISC example description includes the text “The example is subject to change.”  The example is there so that people will be aware of the RISC work’s use of SecEvents and have a pointer to the RISC working group page, where they can get current versions of the RISC specs.  It’s also a good example of using an event payload.

                                                                -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Monday, January 8, 2018 2:50 PM
To: Marius Scurtescu <[email-masked]>
Cc: Mike Jones <[email-masked]>; [email-masked]; Yaron Sheffer <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] SecEvent consensus calls

Phil

On Jan 8, 2018, at 2:21 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Mike.

Marius

On Mon, Jan 8, 2018 at 2:14 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I added a RISC event example to the pull request<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_independentid_Identity-2DEvents_pull_9&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=AxlL2XEJxDhu3SR0U4PqPWCkyVrfkCrgDafyEFrpFjk&e=> with this commit https://github.com/independentid/Identity-Events/pull/9/commits/26c6c49f8c4f6f8bd8117ba005dabcb200f18919<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_independentid_Identity-2DEvents_pull_9_commits_26c6c49f8c4f6f8bd8117ba005dabcb200f18919&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=ckDcXYN5nYORk_CHvIxdhbOUFNZz-_CGy9VjZgU9oGs&e=>.  Thanks to Marius and Adam for providing the RISC information.

                                                                -- Mike

From: Id-event [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mike Jones
Sent: Friday, January 5, 2018 5:37 PM
To: Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] SecEvent consensus calls

I’ve created a PR to enable other editors and WG members to review the proposed changes before they are merged: https://github.com/independentid/Identity-Events/pull/9<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_independentid_Identity-2DEvents_pull_9&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=AxlL2XEJxDhu3SR0U4PqPWCkyVrfkCrgDafyEFrpFjk&e=>.  A summary of the changes made (as found in the changelog) is:
•         Clarified that all "events" values must represent aspects of the same state change that occurred to the subject -- not an aggregation of unrelated events about the subject.
•         Removed ambiguities about the roles of multiple "events" values and the responsibilities of profiling specifications for defining how and when they are used.
•         Corrected places where the term JWT was used when what was actually being discussed was the JWT Claims Set.
•         Addressed terminology inconsistencies. In particular, standardized on using the term "issuer" to align with JWT terminology and the "iss" claim. Previously the term "transmitter" was sometimes used and "issuer" was sometimes used. Likewise, standardized on using the term "recipient" instead of "receiver" for the same reasons.
•         Applied numerous grammar, syntax, and formatting corrections.
I’ve also attached rendered versions, if you prefer to read the updated text in context.

                                                                Best wishes,
                                                                -- Mike

                                                                -- Mike

From: Mike Jones

- What are our interoperability expectations? One of the participants mentioned that his company will only send single events and will "prefer" to receive single events. Can such an implementation be interoperable with all RFC compliant implementations? If we leave too much of the SET semantics for profiles to define, are we sacrificing interoperability?
Mike> My interoperability expectations are that profiles will define the syntax and semantics of particular SETs and implementations of those profiles will be interoperable with one another.  It’s up to the profiles to define whether events must use only a single URI to convey a single aspect of the event or whether multiple URIs are allowed.  Indeed, this was your very suggestion in https://www.ietf.org/mail-archive/web/id-event/current/msg00736.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00736.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=Lk10m2ojWTYy7MoTvUyVBa9k6nb9MnTimy56ebnKgS8&e=> Yaron.  I’m fine with adding text along those lines.  Hopefully clarifying that profiles can dictate that the “events” set must be a singleton will help provide those who want this restriction more comfort with the working group specification.

Mike> Figure 1 in https://tools.ietf.org/html/draft-ietf-secevent-token-03#section-2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D03-23section-2D2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=40rmqKlF3OcLcp4tcGnRwHUJ86p6Wx0XdcbGyyYcdrw&e=> is a SCIM password reset example.  Figure 2 is a logout event example.  Figure 3 is an example consent event.  Figure 4 is a SCIM create event example.  That said, I’m fine adding more examples, for instance, a RISC example or two.

Thanks,
    Yaron

                                                       Thanks,
                                                       -- 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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=P1ygNibseS7ywo99BD5nfQZr507j8Ohd36N2rP7cu4A&e=

---

From: Mike Jones <[email-masked]>
Date: Mon, 8 Jan 2018 22:58:31 +0000

And yes, we can keep updating the RISC example up until I suspect about the time that the spec goes to the RFC editor.

                                                                -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, January 8, 2018 2:56 PM
To: Phil Hunt <[email-masked]>; Marius Scurtescu <[email-masked]>
Cc: [email-masked]; Yaron Sheffer <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] SecEvent consensus calls

                                                                -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Monday, January 8, 2018 2:50 PM
To: Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] SecEvent consensus calls

Phil

Marius

                                                                -- Mike

                                                                Best wishes,
                                                                -- Mike

                                                                -- Mike

From: Mike Jones

Thanks,
    Yaron

                                                       Thanks,
                                                       -- Mike

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 9 Jan 2018 20:44:49 +0000

At the end of section 2.0:
Possible uses of multiple values include:

     *   Values to provide classification information (e.g., threat type or level).
     *   Additions to existing event representations.
     *   Values used to link potential series of events.
     *   Specific-purpose event URIs used between particular Event Issuers and Event Recipients.

This text should be struck and the following sentence should be added to the paragraph above it: “Beyond this, the interpretation of SETs containing multiple event identifiers is out of scope of this specification; Profiling Specifications MAY define their own rules regarding SETs containing multiple event identifiers.”

In the definition for iss in section 2.2:
Note that when a SET is expressing information about a Security Subject for which the SET issuer is not the issuer of the Security Subject, the conflict can be resolved by including the Security Subject issuer value within the event payload (see the events claim).

This text should be struck and replaced with: “In some cases, the SET issuer may not be the issuer of the Security Subject. Therefore, implementers MUST NOT assume they are the same for a given SET, unless the Profiling Specification indicates that this is the case for that SET.”

From: Mike Jones <[email-masked]>
Date: Monday, January 8, 2018 at 2:59 PM
To: Phil Hunt <[email-masked]>, Marius Scurtescu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Yaron Sheffer <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, SecEvent <[email-masked]>
Subject: RE: [Id-event] SecEvent consensus calls

                                                                -- Mike

                                                                -- Mike

Phil

Marius

                                                                -- Mike

                                                                Best wishes,
                                                                -- Mike

                                                                -- Mike

From: Mike Jones

Thanks,
    Yaron

                                                       Thanks,
                                                       -- Mike

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 9 Jan 2018 23:20:11 +0200

In my opinion, Annabelle's new sentence ("beyond that, etc.") can 
coexist with the existing non-normative examples of cases when multiple 
values may be useful. So I wouldn't delete these four bullets.

Thanks,
	Yaron

On 09/01/18 22:44, Richard Backman, Annabelle wrote:
> *At the end of section 2.0:*
> 
>       o Values to provide classification information (e.g., threat type
>         or level).
>       o Additions to existing event representations.
>       o Values used to link potential series of events.
>       o Specific-purpose event URIs used between particular Event
>         Issuers and Event Recipients.
> 
> This text should be struck and the following sentence should be added to 
> the paragraph above it: “Beyond this, the interpretation of SETs 
> containing multiple event identifiers is out of scope of this 
> specification; Profiling Specifications MAY define their own rules 
> regarding SETs containing multiple event identifiers.”
> 
> *In the definition for iss in section 2.2:*
> 
> Note that when a SET is expressing information about a Security Subject 
> for which the SET issuer is not the issuer of the Security Subject, the 
> conflict can be resolved by including the Security Subject issuer value 
> within the event payload (see the events claim).
> 
> This text should be struck and replaced with: “In some cases, the SET 
> issuer may not be the issuer of the Security Subject. Therefore, 
> implementers MUST NOT assume they are the same for a given SET, unless 
> the Profiling Specification indicates that this is the case for that SET.”
> 
> -- 
> 
> *From: *Mike Jones <[email-masked]>
> *Date: *Monday, January 8, 2018 at 2:59 PM
> *To: *Phil Hunt <[email-masked]>, Marius Scurtescu 
> <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Yaron Sheffer 
> <[email-masked]>, "Richard Backman, Annabelle" 
> <[email-masked]>, SecEvent <[email-masked]>
> *Subject: *RE: [Id-event] SecEvent consensus calls
> 
> And yes, we can keep updating the RISC example up until I suspect about 
> the time that the spec goes to the RFC editor.
> 
>                                                                  -- Mike
> 
> *Sent:* Monday, January 8, 2018 2:56 PM
> *To:* Phil Hunt <[email-masked]>; Marius Scurtescu 
> <[email-masked]>
> *Cc:* [email-masked]; Yaron Sheffer <[email-masked]>; Richard 
> Backman, Annabelle <[email-masked]>; SecEvent <[email-masked]>
> You’ll notice that the RISC example description includes the text “The 
> example is subject to change.”  The example is there so that people will 
> be aware of the RISC work’s use of SecEvents and have a pointer to the 
> RISC working group page, where they can get current versions of the RISC 
> specs.  It’s also a good example of using an event payload.
> 
>                                                                  -- Mike
> 
> *From:* Phil Hunt [mailto:[email-masked]]
> *Sent:* Monday, January 8, 2018 2:50 PM
> *To:* Marius Scurtescu <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* Mike Jones <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>; Yaron Sheffer <[email-masked] 
> <mailto:[email-masked]>>; Richard Backman, Annabelle 
> <[email-masked] <mailto:[email-masked]>>; SecEvent 
> <[email-masked] <mailto:[email-masked]>>
> Regarding keeping in sync with profiling specs (eg risc), AFAIK, once 
> published only errata are doable.  Not sure if this type of update can 
> be approached as errata.
> 
> My thought was that all examples in SET are hypothetical and examples 
> are not normative AND subject to change. Readers may need stronger 
> reminding that specs like risc and scim are the official sources. There 
> is some text to this effect already.
> 
> Phil
> 
> 
>     As a general note, please keep in mind that the RISC profile is work
>     in progress. Most likely the subject will not be identified with top
>     level iss+sub but rather with a nested composite claim.
> 
>     On Mon, Jan 8, 2018 at 2:14 PM, Mike Jones
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
> 
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_independentid_Identity-2DEvents_pull_9&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=AxlL2XEJxDhu3SR0U4PqPWCkyVrfkCrgDafyEFrpFjk&e=>
>         with this commit
>         https://github.com/independentid/Identity-Events/pull/9/commits/26c6c49f8c4f6f8bd8117ba005dabcb200f18919
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_independentid_Identity-2DEvents_pull_9_commits_26c6c49f8c4f6f8bd8117ba005dabcb200f18919&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=ckDcXYN5nYORk_CHvIxdhbOUFNZz-_CGy9VjZgU9oGs&e=>. 
>         Thanks to Marius and Adam for providing the RISC information.
> 
>                                                                         
>         -- Mike
> 
>         <mailto:[email-masked]>] *On Behalf Of *Mike Jones
>         *To:* Richard Backman, Annabelle <[email-masked]
>         <mailto:[email-masked]>>; Yaron Sheffer
>         <[email-masked] <mailto:[email-masked]>>; SecEvent
>         <[email-masked] <mailto:[email-masked]>>
>         specification that clarifies the points described earlier in
>         this thread.  This includes clearly specifying the
>         responsibilities of profiling specifications with respect to
>         multiple “events” values, as was requested by Annabelle both at
>         Cisco and in her note just now.  The proposed changes both
>         update the Section 2 (The Security Event Token (SET)) text
>         referred to by Annabelle and add a new paragraph to Section 3
>         (Requirements for SET Profiles) explicitly defining the
>         responsibilities of Profiling Specifications for defining how
>         and when multiple "events" values are (or are not) used.  The
>         text for some of the claims definitions was also adjusted to be
>         unambiguous with respect to these responsibilities.
> 
>         Among the syntax and semantics of SETs that Profiling
>         Specifications define is whether and how multiple eventsvalues
>         are used for SETs conforming to those profiles. Many valid
>         choices are possible. For instance, some profiles might allow
>         multiple event identifiers to be present and specify that any
>         that are not understood by recipients be ignored, thus enabling
>         extensibility. Other profiles might allow multiple event
>         identifiers to be present but require that all be understood if
>         the SET is to be accepted. Some profiles might require that only
>         a single value be present. All such choices are within the scope
>         of Profiling Specifications to define.
> 
>         Hopefully the incorporation of the proposed changes that
>         significantly clarify roles and responsibilities will provide us
>         a basis to finally finish the SET spec soon.  Your feedback is
>         welcomed.
> 
>         I’ve created a PR to enable other editors and WG members to
>         review the proposed changes before they are merged:
>         https://github.com/independentid/Identity-Events/pull/9
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_independentid_Identity-2DEvents_pull_9&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=AxlL2XEJxDhu3SR0U4PqPWCkyVrfkCrgDafyEFrpFjk&e=>.
>         A summary of the changes made (as found in the changelog) is:
> 
>         ·Clarified that all "events" values must represent aspects of
>         the same state change that occurred to the subject -- not an
>         aggregation of unrelated events about the subject.
> 
>         ·Removed ambiguities about the roles of multiple "events" values
>         and the responsibilities of profiling specifications for
>         defining how and when they are used.
> 
>         ·Corrected places where the term JWT was used when what was
>         ·Addressed terminology inconsistencies. In particular,
>         standardized on using the term "issuer" to align with JWT
>         terminology and the "iss" claim. Previously the term
>         "transmitter" was sometimes used and "issuer" was sometimes
>         used. Likewise, standardized on using the term "recipient"
>         instead of "receiver" for the same reasons.
> 
>         ·Applied numerous grammar, syntax, and formatting corrections.
> 
>         *From:* Richard Backman, Annabelle [mailto:[email-masked]]
>         *To:* Mike Jones <[email-masked]
>         <mailto:[email-masked]>>; Yaron Sheffer
>         <[email-masked] <mailto:[email-masked]>>; SecEvent
>         <[email-masked] <mailto:[email-masked]>>
> 
> 
>         Now that the holidays are over I have some time to reply to this
>         and add some additional context for those who were not a part of
>         the discussion Mike referred to.
> 
>         One of the first things that became clear in the discussion was
>         that there was disagreement over the answer to Yaron’s third
>         question, “what are our interoperability expectations [for
>         SET]?” My expectation, assuming a SET format that permits
>         multiple event types within a single token, is that any two
>         arbitrary event types should be combinable. This is why I have
>         argued strongly for clarifying the semantics of multi-part SETs;
>         you can’t combine two event types if they disagree about what it
>         means when you combine event types. Without that compatibility,
>         we’re left with defining an “events” JWT claim and precious
>         little more, and if that’s the case then I have to ask why it
>         takes 8,000 words to do that.
> 
>         My expectation is based off of use cases and examples presented
>         by members of the working group. Putting my RISC hat on, I don’t
>         see use cases there for multi-part SETs, and am happy to have
>         the discussion within RISC over whether or not we mandate
>         single-event SETs in our profile. My only concern is that the
>         spec accurately expresses the consequences and resulting
>         consequences of whatever consensus we reach. If the consensus is
>         that individual profiles should be able to define what it means
>         when two event types are in the same SET, then the SET spec
>         should make that clear: avoid any and all statements about the
>         meaning of a multi-part SET (such as the language in section 2
>         of the current draft), call out defining this as a
>         responsibility of profiling specs, and note the compatibility
>         implications. If the consensus is that profiles should not be
>         able to define this, then we need to actually define it in the
>         SET spec.
> 
>         I’d very much like to hear from others in the working group
>         their thoughts on Yaron’s three questions – the last one in
>         particular as I think everything else falls out from that.
> 
>         -- 
> 
>         *From: *Id-event <[email-masked]
>         <mailto:[email-masked]>> on behalf of Mike Jones
>         <[email-masked] <mailto:[email-masked]>>
>         *To: *Yaron Sheffer <[email-masked]
>         <mailto:[email-masked]>>, SecEvent <[email-masked]
>         <mailto:[email-masked]>>
>         On Wednesday there was an informal discussion among Annabelle,
>         Marius, Phil, Morteza, myself, and a few others about trying to
>         find a good path forward for SET.
> 
>         I opened by asking if people would be happy with us adding
>         language along the lines that Yaron had proposed saying that
>         profiles can restrict the “events” list to a single value. 
>         Annabelle said that that would be OK but wouldn’t solve the
>         whole problem.  Annabelle said that to solve the whole problem,
>         the spec would have to become clear that it’s up to profiles to
>         define what the relationship is among multiple “events” elements
>         when they occur, and indeed, whether they are permitted to
>         occur.  I think that all agreed that clarity on this point is
>         needed for users of the spec.
> 
>         interoperability expectations?” was a great one and said that my
>         answer helped clarify what was and was not intended to be able
>         to be interoperable with and without profile knowledge.  This
>         was another point where I think we all agreed that being
>         super-clear in the spec on this point would be good for
>         developers and profile designers.
> 
>         Phil made the point that if there are multiple elements in the
>         “events” list, they are there because they convey related
>         aspects of a single logical event and because the profile called
>         for this.  An example used in the discussion (which I believe
>         came from Marius) was that “logout”, “session cancelled”, and
>         “account suspended” information could be aspects conveyed of a
>         single logical event residing in a single SET.  Conversely, the
>         “events” set is not to be used for aggregating unrelated
>         information.  I think there was agreement on these points as well.
> 
>         As a result of these positive discussions, I agreed to review
>         the current SET draft and propose any appropriate changes to
>         make sure the points above are super clear to others. 
>         Annabelle, Phil, and Morteza also expressed an interest in doing
>         this and reviewing the proposed clarifications.
> 
>         Finally, I also stated that I would be thrilled to work on a new
>         event subject spec with Annabelle and others wishing to do so
>         and that some of the subject language in Annabelle’s draft is
>         almost certainly applicable.  I would work with others to try to
>         get this to happen fast, as RISC, which I care deeply about,
>         needs it.  Marius also stressed that it was important for this
>         to happen in a timely fashion.
> 
>         To Yaron’s point about wanting more examples, I’ve also asked
>         Marius and Adam for a RISC example or two to include in the
>         working group specification.
> 
>         Hopefully these actions will help get us to a place where we can
>         all agree that we reached the IETF definition of rough
>         consensus.  Thanks all who were there for the positive and
>         productive discussions on Wednesday.
> 
>                                                                         
>         -- Mike
> 
>         *From:* Mike Jones
>         *To:* Yaron Sheffer <[email-masked]
>         <mailto:[email-masked]>>; SecEvent <[email-masked]
>         <mailto:[email-masked]>>
>         *From:* Id-event [mailto:[email-masked]] *On Behalf
>         Of *Yaron Sheffer
>         *To:* SecEvent <[email-masked] <mailto:[email-masked]>>
>         First, I would like to thank all those who shared their opinions
>         on the list and worked to clarify the issues at stake for the
>         benefit of all of us.
> 
>         1. The syntax and semantics of the "events" claim, whether
>         multiple events can be expressed, logical events vs. aspects of
>         events etc.
>         The bulk of the discussion was about issue #1, and in my
>         opinion, if we untangle this issue, it would be much easier to
>         reach consensus on #2 and #3. Unfortunately, in my opinion, we
>         have not reached (the IETF definition of) rough consensus on #1.
>         While the majority of participants expressed the opinion that we
>         should keep the current text as-is, a non-negligible minority
>         had a detailed alternative text and a number of significant
>         We cannot move forward without rough consensus, but clearly we
>         all want to publish a SET RFC as soon as we can, to enable
>         multiple profiles to be developed by other organizations. So if
>         we want to get to an RFC as a group, we need to continue this
>         discussion until we do reach technical consensus. I would like
>         to give this discussion the remaining days of the year (until
>         EOB on Dec. 31). If we have not reached consensus by then, Dick
>         To lead into this discussion, I would like to raise some points
>         that the discussion did not clarify to me:
> 
>         - What is the value of a SET, in addition to its being "a kind
>         of JWT". Specifically, let's assume a software architecture that
>         consists of three layers: SET profile-specific library, generic
>         SET processor, generic JWT library. What would be the
>         functionality (or the added value) of the middle layer?
> 
>         representation of information about an event that occurred.  It
>         defines an “events” JWT claim to represent this information.  I
>         actually think that many use cases **will not** use a generic
>         SET processor – just like a lot of use cases don’t develop a
>         generic processor for other JWT claims.  Yes, a generic JWT
>         library will often be used, but for simple event use cases, I
>         suspect that the “events” claim will be directly processed by
>         the application, without the use of additional middleware.
> 
> 
>         - What are the existing implementations that prevent change to
>         the current spec, even changes as trivial as renaming "events"
>         to "event"? Are there any production or near-production
>         implementations in addition to the OIDC Back Channel Logout
>         (which is arguably a trivial use of SET)? From an IETF process
>         point of view, I'd like to point out that any I-D is completely
>         open to changes until actual publication as an RFC, and
>         certainly until it is delivered to the IESG.
> 
>         Mike> There are a number of implementations of OpenID Connect
>         Back-Channel Logout that are compatible with the working group
>         draft.  This specification has reached the Implementer’s Draft
>         stage.  Strictly speaking, it intentionally did not take a
>         dependency on SET exactly because it might change.  Should a
>         breaking change occur in SET, the OpenID Connect working group
>         will have to decide wither to track that change or stay with the
>         syntax it is already using.
> 
>         Mike> If the proposed alternative syntax were simpler for most
>         use cases than the existing one, I might be open to it, but it
>         reintroduces a distinction between primary and secondary events
>         that the working group long ago decided against. It introduces
>         very complicated and deeply nested “related events” and
>         “extensions” syntax – none of which is needed in the working
>         group draft.  We should stay with what’s simple and what already
>         works well.
> 
> 
>         - What are our interoperability expectations? One of the
>         participants mentioned that his company will only send single
>         events and will "prefer" to receive single events. Can such an
>         implementation be interoperable with all RFC compliant
>         implementations? If we leave too much of the SET semantics for
>         profiles to define, are we sacrificing interoperability?
> 
>         Mike> My interoperability expectations are that profiles will
>         define the syntax and semantics of particular SETs and
>         implementations of those profiles will be interoperable with one
>         another.  It’s up to the profiles to define whether events must
>         use only a single URI to convey a single aspect of the event or
>         whether multiple URIs are allowed.  Indeed, this was your very
>         suggestion in
>         https://www.ietf.org/mail-archive/web/id-event/current/msg00736.html
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00736.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=Lk10m2ojWTYy7MoTvUyVBa9k6nb9MnTimy56ebnKgS8&e=>
>         Yaron.  I’m fine with adding text along those lines.  Hopefully
>         clarifying that profiles can dictate that the “events” set must
>         be a singleton will help provide those who want this restriction
>         more comfort with the working group specification.
> 
>         Mike> This is exactly parallel to the interoperability
>         expectations for JWTs.  Particular JWT profiles will have
>         interoperable implementations but there is no expectation that
>         unrelated JWT profiles will interoperate, other than that they
>         use the same cryptographic formats.  An ID Token is not the same
>         as a caller-ID record, and that’s just fine.
> 
> 
>         Lastly, I must say that both the WG draft and the alternative
>         draft woefully lack worked out examples of concrete events
>         ("logout", "email change" etc.), which would have clarified the
>         similarities and differences between the drafts and might have
>         made this discussion easier and shorter.
> 
>         Mike> Figure 1 in
>         https://tools.ietf.org/html/draft-ietf-secevent-token-03#section-2
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D03-23section-2D2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=40rmqKlF3OcLcp4tcGnRwHUJ86p6Wx0XdcbGyyYcdrw&e=>
>         is a SCIM password reset example.  Figure 2 is a logout event
>         example.  Figure 3 is an example consent event.  Figure 4 is a
>         SCIM create event example.  That said, I’m fine adding more
>     [email-masked] <mailto:[email-masked]>

---

From: Mike Jones <[email-masked]>
Date: Tue, 9 Jan 2018 21:22:09 +0000

I'm fine with applying Annabelle's other change and not striking the four bullets, as you suggest Yaron.

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Tuesday, January 9, 2018 1:20 PM
To: Richard Backman, Annabelle <[email-masked]>; Mike Jones <[email-masked]>; Phil Hunt <[email-masked]>; Marius Scurtescu <[email-masked]>
Cc: [email-masked]; SecEvent <[email-masked]>
Subject: Re: [Id-event] SecEvent consensus calls

Thanks,
	Yaron

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 9 Jan 2018 23:00:09 +0000

I’m fine with keeping the bullets if the new sentence is added before it. I also suggest changing “Possible uses of multiple values include” to “…include but are not limited to:” or replacing that with something like “Some examples of possible uses of multiple values are:”.

On 1/9/18, 1:23 PM, "Mike Jones" <[email-masked]> wrote:

    -----Original Message-----
    From: Yaron Sheffer [mailto:[email-masked]] 
    Sent: Tuesday, January 9, 2018 1:20 PM
    To: Richard Backman, Annabelle <[email-masked]>; Mike Jones <[email-masked]>; Phil Hunt <[email-masked]>; Marius Scurtescu <[email-masked]>
    Cc: [email-masked]; SecEvent <[email-masked]>
    Subject: Re: [Id-event] SecEvent consensus calls

    Thanks,
    	Yaron

---

From: Mike Jones <[email-masked]>
Date: Tue, 9 Jan 2018 23:46:20 +0000

By the new sentence, are you referring to “Beyond this, the interpretation of SETs containing multiple event identifiers is out of scope of this specification; Profiling Specifications MAY define their own rules regarding SETs containing multiple event identifiers.”?  This largely duplicates what is already said in the new paragraph in the profile requirements section.  I don't think we need to say it twice.  I'll look at referencing that section in this one instead.

I'm fine with the "includes but limited to" language.

				-- Mike

    
    -----Original Message-----
    From: Yaron Sheffer [mailto:[email-masked]] 
    Sent: Tuesday, January 9, 2018 1:20 PM
    To: Richard Backman, Annabelle <[email-masked]>; Mike Jones <[email-masked]>; Phil Hunt <[email-masked]>; Marius Scurtescu <[email-masked]>
    Cc: [email-masked]; SecEvent <[email-masked]>
    Subject: Re: [Id-event] SecEvent consensus calls

    Thanks,
    	Yaron

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 9 Jan 2018 16:54:36 -0800

> the time that the spec goes to the RFC editor.

Sounds good, thanks Mike.

>
>
>                                                                 -- Mike
>
>
>
> *From:* Id-event [mailto:[email-masked]] * On Behalf Of *Mike
> Jones
> *To:* Phil Hunt <[email-masked]>; Marius Scurtescu <
> [email-masked]>
> example is subject to change.”  The example is there so that people will be
> aware of the RISC work’s use of SecEvents and have a pointer to the RISC
> working group page, where they can get current versions of the RISC specs.
> It’s also a good example of using an event payload.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Phil Hunt [mailto:[email-masked] <[email-masked]>]
> *To:* Marius Scurtescu <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; [email-masked]; Yaron
> Sheffer <[email-masked]>; Richard Backman, Annabelle <
> [email-masked]>; SecEvent <[email-masked]>
> published only errata are doable.  Not sure if this type of update can be
> approached as errata.
>
>
>
> My thought was that all examples in SET are hypothetical and examples are
> not normative AND subject to change. Readers may need stronger reminding
> that specs like risc and scim are the official sources. There is some text
> to this effect already.
>
>
>
> Phil
>
>
> with this commit https://github.com/independentid/Identity-Events/
> pull/9/commits/26c6c49f8c4f6f8bd8117ba005dabcb200f18919
> independentid/Identity-Events/pull/9
> archive/web/id-event/current/msg00736.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00736.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=Lk10m2ojWTYy7MoTvUyVBa9k6nb9MnTimy56ebnKgS8&e=> Yaron.
> I’m fine with adding text along those lines.  Hopefully clarifying that
> profiles can dictate that the “events” set must be a singleton will help
> provide those who want this restriction more comfort with the working group
> specification.
>
>
>
> draft-ietf-secevent-token-03#section-2
> is a SCIM password reset example.  Figure 2 is a logout event example.
> Figure 3 is an example consent event.  Figure 4 is a SCIM create event
> example.  That said, I’m fine adding more examples, for instance, a RISC
> example or two.
>
>
> Thanks,
>     Yaron
>
>
>
>                                                        Thanks,
>
>                                                        -- Mike
>
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=
> ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=
> P1ygNibseS7ywo99BD5nfQZr507j8Ohd36N2rP7cu4A&e=
>
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 19 Jan 2018 01:05:57 +0000

This commit https://github.com/selfissued/Identity-Events/commit/570bcff4d7bb1b268e0066bf49b4c2f6fb5337d6 applies the wording clarifications suggested by Annabelle Bachman and Yaron Sheffer.

If I don’t hear other suggestions for improvement by end of business tomorrow, I’ll plan to merge https://github.com/independentid/Identity-Events/pull/9 and publish -04.

                                                                Best wishes,
                                                                -- Mike

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Tuesday, January 9, 2018 4:55 PM
To: Mike Jones <[email-masked]>
Cc: Phil Hunt <[email-masked]>; [email-masked]; Yaron Sheffer <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] SecEvent consensus calls

On Mon, Jan 8, 2018 at 2:58 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
And yes, we can keep updating the RISC example up until I suspect about the time that the spec goes to the RFC editor.

                                                                -- Mike

From: Id-event [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mike Jones
Sent: Monday, January 8, 2018 2:56 PM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>; Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>

                                                                -- Mike

Phil

Marius

                                                                -- Mike

                                                                Best wishes,
                                                                -- Mike

                                                                -- Mike

From: Mike Jones

Thanks,
    Yaron

                                                       Thanks,
                                                       -- Mike

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 19 Jan 2018 18:23:38 +0000

The -03 draft is ambiguous on the degree of interoperability across profiles, but this text takes a clear position on the issue. Since Yaron has raised the question of interoperability expectations within the working group and there is disagreement on the answer, I’d like to see a call for consensus before this text is uploaded as -04.

  1.  “Backman” with a K, not “Bachman” (Minor quibble, since it’s just in the changelog :P )

  2.  I like the reference to the “Requirements for SET Profiles” section that you added to section 2.0. I suspect developers that want to use existing SET profiles and are not profiling SET themselves will pay less attention to the former section, so mentioning this point in both sections has value.

  3.  In the addition to section 2.2 based on my suggestion: Is “…for that kind of SET” the right terminology we want to use? This encourages a mental model in which a Profiling Specification defines new types of tokens that are based on SET, as opposed to new types of events to be packaged within a SET. For example, it’s the difference between the RISC spec saying “a RISC Event Token is a SET that contains a RISC event” versus “RISC defines the following set of events, to be transmitted within SETs.” To date my mental model has been the latter. This difference may be another manifestation of differences in interoperability expectations (i.e. Yaron’s third question), and if so I’m fine with the current language if the consensus is that there is no expectation of interoperability between profiles. I just want to make sure that is a conscious decision we’re making.

  4.  In Singapore, we’d discussed and found general agreement on a few other changes to claim definitions in the alternate draft that I think also apply here:
     *   Strike the “NumericDate” text from “iat” as it’s redundant with the definition in JWT, which is already referenced.
     *   Require that in the absence of a “toe” claim, recipients MUST NOT interpret the “iat” claim as also representing the time of event. Without this, transmitters have no way to express that they either don’t know or are not willing to share the actual time of the event being described.
     *   Remove “txn” and introduce it in a separate draft, as it is intended to be used in various kinds of JWTs beyond just SET.

From: Mike Jones <[email-masked]>
Date: Thursday, January 18, 2018 at 5:06 PM
To: Marius Scurtescu <[email-masked]>
Cc: Phil Hunt <[email-masked]>, "[email-masked]" <[email-masked]>, Yaron Sheffer <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, SecEvent <[email-masked]>
Subject: RE: [Id-event] SecEvent consensus calls

                                                                Best wishes,
                                                                -- Mike

                                                                -- Mike

                                                                -- Mike

Phil

Marius

                                                                -- Mike

                                                                Best wishes,
                                                                -- Mike

                                                                -- Mike

From: Mike Jones

Thanks,
    Yaron

                                                       Thanks,
                                                       -- Mike

---

From: Mike Jones <[email-masked]>
Date: Fri, 19 Jan 2018 19:08:32 +0000

Thanks for taking the time to review the proposed changes, Annabelle.  Replies inline…

From: Richard Backman, Annabelle [mailto:[email-masked]]
Sent: Friday, January 19, 2018 10:24 AM
To: Mike Jones <[email-masked]>; Marius Scurtescu <[email-masked]>
Cc: Phil Hunt <[email-masked]>; [email-masked]; Yaron Sheffer <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] SecEvent consensus calls

If the updated text changed the meaning of the draft, it would be reasonable to ask for a consensus call, but since all the changes are strictly clarifications of the explanations of the semantics already in -03, a consensus call shouldn’t be necessary.  Also, asking people to review a non-published draft and base a consensus call doesn’t seem reasonable to me.  Publishing -04 will make the clarifications much more accessible to the working group and reviewers.

-03 isn’t going away.  We can always revert to parts if it in a future draft if there’s consensus to do so.

Thanks – will fix!

  1.  I like the reference to the “Requirements for SET Profiles” section that you added to section 2.0. I suspect developers that want to use existing SET profiles and are not profiling SET themselves will pay less attention to the former section, so mentioning this point in both sections has value.
Thanks

  1.  In the addition to section 2.2 based on my suggestion: Is “…for that kind of SET” the right terminology we want to use? This encourages a mental model in which a Profiling Specification defines new types of tokens that are based on SET, as opposed to new types of events to be packaged within a SET. For example, it’s the difference between the RISC spec saying “a RISC Event Token is a SET that contains a RISC event” versus “RISC defines the following set of events, to be transmitted within SETs.” To date my mental model has been the latter. This difference may be another manifestation of differences in interoperability expectations (i.e. Yaron’s third question), and if so I’m fine with the current language if the consensus is that there is no expectation of interoperability between profiles. I just want to make sure that is a conscious decision we’re making.
I can change to more neutral language along the lines of “SETs conforming to a profile” rather than “that kind of SET”.

  1.  In Singapore, we’d discussed and found general agreement on a few other changes to claim definitions in the alternate draft that I think also apply here:
     *   Strike the “NumericDate” text from “iat” as it’s redundant with the definition in JWT, which is already referenced.

I’m fine with this change since it’s strictly editorial.

This is the first change proposed that changes the semantics of the specification.  I’ll check the minutes later today, but I don’t believe that a decision was made about this, although it may have been discussed in Singapore.  For that matter, any decision would have to include discussion on the list, which I believe hasn’t happened.  This sounds like a potential change to include in -05, if there’s support for it.

Same feedback as for (b).  This changes the semantics of the draft, so shouldn’t go into -04 without working group discussion.  -04 contains only clarifications and no semantic changes.

Thanks for sweating the details…

                                                       -- Mike

From: Mike Jones <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 18, 2018 at 5:06 PM
To: Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Cc: Phil Hunt <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Id-event] SecEvent consensus calls

                                                                Best wishes,
                                                                -- Mike

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Tuesday, January 9, 2018 4:55 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Phil Hunt <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] SecEvent consensus calls

                                                                -- Mike

                                                                -- Mike

Phil

Marius

                                                                -- Mike

                                                                Best wishes,
                                                                -- Mike

                                                                -- Mike

From: Mike Jones

Thanks,
    Yaron

                                                       Thanks,
                                                       -- Mike

---

From: Phil Hunt <[email-masked]>
Date: Fri, 19 Jan 2018 11:14:03 -0800

Phil

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

> On Jan 19, 2018, at 10:23 AM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> “Backman” with a K, not “Bachman” (Minor quibble, since it’s just in the changelog :P )
> 
> I like the reference to the “Requirements for SET Profiles” section that you added to section 2.0. I suspect developers that want to use existing SET profiles and are not profiling SET themselves will pay less attention to the former section, so mentioning this point in both sections has value.
> 
> In the addition to section 2.2 based on my suggestion: Is “…for that kind of SET” the right terminology we want to use? This encourages a mental model in which a Profiling Specification defines new types of tokens that are based on SET, as opposed to new types of events to be packaged within a SET. For example, it’s the difference between the RISC spec saying “a RISC Event Token is a SET that contains a RISC event” versus “RISC defines the following set of events, to be transmitted within SETs.” To date my mental model has been the latter. This difference may be another manifestation of differences in interoperability expectations (i.e. Yaron’s third question), and if so I’m fine with the current language if the consensus is that there is no expectation of interoperability between profiles. I just want to make sure that is a conscious decision we’re making.
> 
> In Singapore, we’d discussed and found general agreement on a few other changes to claim definitions in the alternate draft that I think also apply here:
> Strike the “NumericDate” text from “iat” as it’s redundant with the definition in JWT, which is already referenced.
> Require that in the absence of a “toe” claim, recipients MUST NOT interpret the “iat” claim as also representing the time of event. Without this, transmitters have no way to express that they either don’t know or are not willing to share the actual time of the event being described.

> Remove “txn” and introduce it in a separate draft, as it is intended to be used in various kinds of JWTs beyond just SET.

<Phil>
I disagree with this,  Txn is core functionality that should be available. It is already defined and included. Let’s not introduce breaking change.

Txn is not profile specific and needs to be usable in all SETs.  The definition is simple and does not warrant a separate draft where common libraries will likely miss or over look this.

> This commit https://github.com/selfissued/Identity-Events/commit/570bcff4d7bb1b268e0066bf49b4c2f6fb5337d6 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_selfissued_Identity-2DEvents_commit_570bcff4d7bb1b268e0066bf49b4c2f6fb5337d6&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ZAKchxMcXA9mUBpg6nSAZsOjtv6c6l_6KHfBAzGdcVw&s=imVcvv-MqXyyn7UqDCtfSONuy1vkSgiviQ4-bZa577U&e=> applies the wording clarifications suggested by Annabelle Bachman and Yaron Sheffer.
>  
> If I don’t hear other suggestions for improvement by end of business tomorrow, I’ll plan to merge https://github.com/independentid/Identity-Events/pull/9 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_independentid_Identity-2DEvents_pull_9&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ZAKchxMcXA9mUBpg6nSAZsOjtv6c6l_6KHfBAzGdcVw&s=N6l20en-SKznEKoKmB91nE-IokLrPqbuVOnGmooEEqM&e=> and publish -04.
>  
>                                                                 Best wishes,
>                                                                 -- Mike
>  
> On Mon, Jan 8, 2018 at 2:58 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Mike Jones
>> To: Phil Hunt <[email-masked] <mailto:[email-masked]>>; Marius Scurtescu <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>; Yaron Sheffer <[email-masked] <mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>>; SecEvent <[email-masked] <mailto:[email-masked]>>
>> 
>> From: Phil Hunt [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Marius Scurtescu <[email-masked] <mailto:[email-masked]>>
>> Cc: Mike Jones <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Yaron Sheffer <[email-masked] <mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>>; SecEvent <[email-masked] <mailto:[email-masked]>>
>> On Jan 8, 2018, at 2:21 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> Thanks Mike.
>>>  
>>> On Mon, Jan 8, 2018 at 2:14 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>>> I added a RISC event example to the pull request <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_independentid_Identity-2DEvents_pull_9&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=AxlL2XEJxDhu3SR0U4PqPWCkyVrfkCrgDafyEFrpFjk&e=> with this commit https://github.com/independentid/Identity-Events/pull/9/commits/26c6c49f8c4f6f8bd8117ba005dabcb200f18919 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_independentid_Identity-2DEvents_pull_9_commits_26c6c49f8c4f6f8bd8117ba005dabcb200f18919&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=ckDcXYN5nYORk_CHvIxdhbOUFNZz-_CGy9VjZgU9oGs&e=>.  Thanks to Marius and Adam for providing the RISC information.
>>>>  
>>>>                                                                 -- Mike
>>>>  
>>>> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Mike Jones
>>>> To: Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>>; Yaron Sheffer <[email-masked] <mailto:[email-masked]>>; SecEvent <[email-masked] <mailto:[email-masked]>>
>>>> Among the syntax and semantics of SETs that Profiling Specifications define is whether and how multiple eventsvalues are used for SETs conforming to those profiles. Many valid choices are possible. For instance, some profiles might allow multiple event identifiers to be present and specify that any that are not understood by recipients be ignored, thus enabling extensibility. Other profiles might allow multiple event identifiers to be present but require that all be understood if the SET is to be accepted. Some profiles might require that only a single value be present. All such choices are within the scope of Profiling Specifications to define.
>>>>  
>>>> I’ve created a PR to enable other editors and WG members to review the proposed changes before they are merged:https://github.com/independentid/Identity-Events/pull/9 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_independentid_Identity-2DEvents_pull_9&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=AxlL2XEJxDhu3SR0U4PqPWCkyVrfkCrgDafyEFrpFjk&e=>.  A summary of the changes made (as found in the changelog) is:
>>>> From: Richard Backman, Annabelle [mailto:[email-masked] <mailto:[email-masked]>] 
>>>> To: Mike Jones <[email-masked] <mailto:[email-masked]>>; Yaron Sheffer <[email-masked] <mailto:[email-masked]>>; SecEvent <[email-masked] <mailto:[email-masked]>>
>>>> 
>>>> From: Id-event <[email-masked] <mailto:[email-masked]>> on behalf of Mike Jones <[email-masked] <mailto:[email-masked]>>
>>>> To: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, SecEvent <[email-masked] <mailto:[email-masked]>>
>>>> To: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>; SecEvent <[email-masked] <mailto:[email-masked]>>
>>>> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Yaron Sheffer
>>>> To: SecEvent <[email-masked] <mailto:[email-masked]>>
>>>> Mike> My interoperability expectations are that profiles will define the syntax and semantics of particular SETs and implementations of those profiles will be interoperable with one another.  It’s up to the profiles to define whether events must use only a single URI to convey a single aspect of the event or whether multiple URIs are allowed.  Indeed, this was your very suggestion inhttps://www.ietf.org/mail-archive/web/id-event/current/msg00736.html <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00736.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=Lk10m2ojWTYy7MoTvUyVBa9k6nb9MnTimy56ebnKgS8&e=> Yaron.  I’m fine with adding text along those lines.  Hopefully clarifying that profiles can dictate that the “events” set must be a singleton will help provide those who want this restriction more comfort with the working group specification.
>>>>  
>>>> Mike> Figure 1 in https://tools.ietf.org/html/draft-ietf-secevent-token-03#section-2 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D03-23section-2D2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=40rmqKlF3OcLcp4tcGnRwHUJ86p6Wx0XdcbGyyYcdrw&e=> is a SCIM password reset example.  Figure 2 is a logout event example.  Figure 3 is an example consent event.  Figure 4 is a SCIM create event example.  That said, I’m fine adding more examples, for instance, a RISC example or two.
>>>> 
>>>> Thanks,
>>>>     Yaron
>>>>  
>>>>                                                        Thanks,
>>>>                                                        -- Mike
>>> 
>>>  
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=P1ygNibseS7ywo99BD5nfQZr507j8Ohd36N2rP7cu4A&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=P1ygNibseS7ywo99BD5nfQZr507j8Ohd36N2rP7cu4A&e=>
>  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ZAKchxMcXA9mUBpg6nSAZsOjtv6c6l_6KHfBAzGdcVw&s=W4XUDb9URsyOsr7q5fUv-khAYaHlwKZyCKlrMry7arg&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ZAKchxMcXA9mUBpg6nSAZsOjtv6c6l_6KHfBAzGdcVw&s=W4XUDb9URsyOsr7q5fUv-khAYaHlwKZyCKlrMry7arg&e=>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 19 Jan 2018 19:36:47 +0000

The consensus call is on the intended degree of interoperability between SET profiles, not on your draft. I find that clarifying questions about fundamental requirements instead of continuing to build according to assumptions results in less work in the long term.

In any case, I don’t understand your objection to people discussing changes that haven’t been published through the IETF data tracker yet. That’s literally what we’ve been doing on this entire email thread, as well as the focus of the vast majority of traffic on this list and the lists for many other working groups.

From: Mike Jones <[email-masked]>
Date: Friday, January 19, 2018 at 11:09 AM
To: "Richard Backman, Annabelle" <[email-masked]>, Marius Scurtescu <[email-masked]>
Cc: Phil Hunt <[email-masked]>, "[email-masked]" <[email-masked]>, Yaron Sheffer <[email-masked]>, SecEvent <[email-masked]>
Subject: RE: [Id-event] SecEvent consensus calls

                                                       -- Mike

                                                                Best wishes,
                                                                -- Mike

                                                                -- Mike

                                                                -- Mike

Phil

Marius

                                                                -- Mike

                                                                Best wishes,
                                                                -- Mike

                                                                -- Mike

From: Mike Jones

Thanks,
    Yaron

                                                       Thanks,
                                                       -- Mike

---

From: Mike Jones <[email-masked]>
Date: Fri, 19 Jan 2018 21:04:56 +0000

OK – if the consensus call you want is about the interoperability assumptions that Yaron asked about, then the updates in the pull request are orthogonal to this, as they don’t change the status quo at all, other than to make obvious things that were already true, but that were not previously as clearly stated.  Net, I believe the publishing the clarifications – including those you authored, will help us have a more informed interoperability discussion.

Note too that there a bunch of editorial improvements that we’d need to make anyway, regardless of the interoperability discussion.  The full summary of changes from the current history entry are:
·         Clarified that all "events" values must represent aspects of the same state change that occurred to the subject -- not an aggregation of unrelated events about the subject.
·         Removed ambiguities about the roles of multiple "events" values and the responsibilities of profiling specifications for defining how and when they are used.
·         Corrected places where the term JWT was used when what was actually being discussed was the JWT Claims Set.
·         Addressed terminology inconsistencies. In particular, standardized on using the term "issuer" to align with JWT terminology and the "iss" claim. Previously the term "transmitter" was sometimes used and "issuer" was sometimes used. Likewise, standardized on using the term "recipient" instead of "receiver" for the same reasons.
·         Added a RISC event example, courtesy of Marius Scurtescu.
·         Applied wording clarifications suggested by Annabelle Backman and Yaron Sheffer.
·         Applied numerous grammar, syntax, and formatting corrections.
Therefore, I think these should be published soon.  Part of why I believe that is then the normal IETF tool chain can be used.  As an example, I can see the diffs between -02 and -03 as https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-secevent-token-03.txt or as https://tools.ietf.org/rfcdiff?url2=draft-ietf-secevent-token-03.txt – depending upon my preferences.  People can’t do that while the draft remains unpublished.

Finally, to be clear, changing the current interoperability assumptions would entail a wholesale rewrite of many sections and likely breaking changes.  The working group could decide to do that (although the latest poll results say that the majority of people are not in favor of that) but any such changes would go into a draft after -04 – not the upcoming draft.

                                                                -- Mike

Sent: Friday, January 19, 2018 11:37 AM

From: Mike Jones <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 19, 2018 at 11:09 AM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Cc: Phil Hunt <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Id-event] SecEvent consensus calls

From: Richard Backman, Annabelle [mailto:[email-masked]]
Sent: Friday, January 19, 2018 10:24 AM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>; Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Cc: Phil Hunt <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] SecEvent consensus calls

                                                       -- Mike

                                                                Best wishes,
                                                                -- Mike

                                                                -- Mike

                                                                -- Mike

Phil

Marius

                                                                -- Mike

                                                                Best wishes,
                                                                -- Mike

                                                                -- Mike

From: Mike Jones

Thanks,
    Yaron

                                                       Thanks,
                                                       -- Mike

---

From: Justin Richer <[email-masked]>
Date: Fri, 19 Jan 2018 16:34:50 -0500

+1 to this point, I’m still not convinced we’re defining interop at the right layer

> On Jan 19, 2018, at 2:36 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> From: Mike Jones <[email-masked] <mailto:[email-masked]>>
> Cc: Phil Hunt <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, SecEvent <[email-masked] <mailto:[email-masked]>>
> This commit https://github.com/selfissued/Identity-Events/commit/570bcff4d7bb1b268e0066bf49b4c2f6fb5337d6 <https://github.com/selfissued/Identity-Events/commit/570bcff4d7bb1b268e0066bf49b4c2f6fb5337d6> applies the wording clarifications suggested by Annabelle Bachman and Yaron Sheffer.
>  
> If I don’t hear other suggestions for improvement by end of business tomorrow, I’ll plan to merge https://github.com/independentid/Identity-Events/pull/9 <https://github.com/independentid/Identity-Events/pull/9> and publish -04.
>  
>                                                                 Best wishes,
>                                                                 -- Mike
>  
> From: Marius Scurtescu [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
> Cc: Phil Hunt <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Yaron Sheffer <[email-masked] <mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>>; SecEvent <[email-masked] <mailto:[email-masked]>>
>>>> I’ve created a PR to enable other editors and WG members to review the proposed changes before they are merged: https://github.com/independentid/Identity-Events/pull/9 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_independentid_Identity-2DEvents_pull_9&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=AxlL2XEJxDhu3SR0U4PqPWCkyVrfkCrgDafyEFrpFjk&e=>.  A summary of the changes made (as found in the changelog) is:
>>>> Mike> My interoperability expectations are that profiles will define the syntax and semantics of particular SETs and implementations of those profiles will be interoperable with one another.  It’s up to the profiles to define whether events must use only a single URI to convey a single aspect of the event or whether multiple URIs are allowed.  Indeed, this was your very suggestion in https://www.ietf.org/mail-archive/web/id-event/current/msg00736.html <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00736.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=Lk10m2ojWTYy7MoTvUyVBa9k6nb9MnTimy56ebnKgS8&e=> Yaron.  I’m fine with adding text along those lines.  Hopefully clarifying that profiles can dictate that the “events” set must be a singleton will help provide those who want this restriction more comfort with the working group specification.
>>>>  
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Mike Jones <[email-masked]>
Date: Sun, 21 Jan 2018 05:17:34 +0000

Updating the status on this thread, as I promised to do in this December 22nd, 2017 note in the thread<https://mailarchive.ietf.org/arch/msg/id-event/cxoBD3pmqr4gWaJ_LuYFrHwmQNk>, the just-posted draft-04<https://tools.ietf.org/html/draft-ietf-secevent-token-04> applies the clarifications requested in the December author’s meeting at Cisco (thanks Morteza!), which were the result informal discussions among Annabelle, Marius, Phil, Morteza, myself, and a few others about trying to find a good path forward for SET.  After these requested clarifications had been discussed and reviewed on the mailing list, I published them as draft -04 today.

The new draft should make it very clear to both profilers and implementers that profiles determine the claims and payload usage of the SETS that they define, as well as their use (or non-use) of multi-valued “events” sets.  Clearly defining the semantics was one of Annabelle’s main asks, which I totally support.

The draft provides a clear answer to Yaron’s important third question “What are our interoperability expectations?” – which is, that interoperability is enabled among profiles understood and supported by an implementation.  This provides exactly the same interoperability expectations (by design) as those for JWTs.  For JWTs, implementations support and understand particular profiles of JWTs, such as ID Tokens, caller-ID records, etc.  These are designed for and serve the needs of specific use cases.  There is no expectation that an implementation supporting one profile – for instance, ID Tokens, will be interoperable with those supporting unrelated profiles, such as caller-ID records.  The same is true of SETs.

Thanks to Annabelle, Marius, Phil, Morteza, Yaron, and others for helping us reach this point.

                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, January 19, 2018 1:05 PM
To: Richard Backman, Annabelle <[email-masked]>; Marius Scurtescu <[email-masked]>
Cc: [email-masked]; Yaron Sheffer <[email-masked]>; SecEvent <[email-masked]>; Phil Hunt <[email-masked]>
Subject: Re: [Id-event] SecEvent consensus calls

                                                                -- Mike

                                                       -- Mike

                                                                Best wishes,
                                                                -- Mike

                                                                -- Mike

                                                                -- Mike

Phil

Marius

                                                                -- Mike

                                                                Best wishes,
                                                                -- Mike

                                                                -- Mike

From: Mike Jones

Thanks,
    Yaron

                                                       Thanks,
                                                       -- Mike