Subject: [Id-event] SecEvent consensus calls

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 Dec 2017 18:19:07 +0200

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?

- 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.

- 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?

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.

Thanks,
     Yaron

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Dec 2017 16:54:25 +0000

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]>
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.
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, 23 Dec 2017 00:38:56 +0000

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]] 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

Thanks,
    Yaron

                                                       Thanks,
                                                       -- Mike

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 30 Dec 2017 20:58:49 +0200

Having Dec. 31 as a deadline was an obvious mistake. Enjoy your 
holidays, and let's discuss our way forward in the coming week when 
people are back from vacation.

Happy New Year!

	Yaron