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 <mscurtescu@google.com> 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 <Michael.Jones@microsoft.com> 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
>> 
>>  
>> 
>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Mike Jones
>> Sent: Friday, January 5, 2018 5:37 PM
>> To: Richard Backman, Annabelle <richanna@amazon.com>; Yaron Sheffer <yaronf.ietf@gmail.com>; SecEvent <id-event@ietf.org>
>> 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.
>> 
>>  
>> 
>> 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:richanna@amazon.com] 
>> Sent: Friday, January 5, 2018 4:08 PM
>> To: Mike Jones <Michael.Jones@microsoft.com>; Yaron Sheffer <yaronf.ietf@gmail.com>; SecEvent <id-event@ietf.org>
>> 
>> 
>> 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.
>> 
>>                                                                                                                                                                                                                                            
>> 
>> -- 
>> 
>> Annabelle Richard Backman
>> 
>> Amazon – Identity Services
>> 
>>  
>> 
>>  
>> 
>> From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.com>
>> Date: Friday, December 22, 2017 at 4:40 PM
>> To: Yaron Sheffer <yaronf.ietf@gmail.com>, SecEvent <id-event@ietf.org>
>> 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 <yaronf.ietf@gmail.com>; SecEvent <id-event@ietf.org>
>> Subject: RE: [Id-event] SecEvent consensus calls
>> 
>>  
>> 
>> Thanks, Yaron.  Replies are inline prefixed by “Mike>”.
>> 
>>  
>> 
>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Yaron Sheffer
>> Sent: Wednesday, December 20, 2017 8:19 AM
>> To: SecEvent <id-event@ietf.org>
>> 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
>> 
> 
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ysy1ypDgdX4gm8giXPz4jo1xnB_X_000CogLJMk_Q_g&s=P1ygNibseS7ywo99BD5nfQZr507j8Ohd36N2rP7cu4A&e=