Subject: [Id-event] Use cases for multiple events per SET?

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 24 Oct 2017 02:02:17 +0000

The current draft of the SET spec allows for expressing multiple events within the same token, which introduces additional complexity and room for ambiguous semantics. We’ve discussed this in the OIDF RISC working group and the current consensus there is that RISC will require that RISC events must be the only event in the SET, having identified ways to clearly and easily support the handful of use cases for multiple events per token that people have raised. With that context in mind, I propose striking the definition of the “events” claim from the Security Event Token spec, and replacing it with the following definition for an “event” claim (singular):

event
A JSON object containing an "event_type" member whose value is a URI representing a type of event defined in a Profiling Specification. The object MAY otherwise be empty, or MAY contain additional members as described by the Profiling Specification.

Here is the example SET from section 2.3, rewritten with this change mind:
{
  "jti": "4d3559ec67504aaba65d40b0363faad8",
  "iat": 1458496404,
 "iss": "https://scim.example.com",
  "aud": [
    "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
    "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
  ],

  "event": {
    "event_type": "urn:ietf:params:scim:event:create",
    "ref": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
    "attributes": ["id", "name", "userName", "password", "emails"]
  }
}

Does anyone in the working group have use cases for SETs that cannot be met by this proposed text? Within RISC, we identified three use cases, with solutions outlined below:

Extensions
Event extension mechanisms can be defined internal to the event object. A simple approach would be to  define an “extensions” member that is a list of event objects (or set resembling the “events” claim as defined in the current spec). This has the advantage of making it clear in the data structure that there is a single primary event, with zero or more extensions. There is no room for confusion over which event is primary, or if there is a primary event at all. I would be fine with adding something like this to my proposed text, if there is consensus that it is broadly useful.

Aliases
This use case was brought up in the context of migrating clients from draft event names to standardized event names. In this case, the event transmitter can transmit two tokens for the logical event, one using the old name and another using the new name.

Related Events
The SET spec defines the txn claim as a means of correlating independent tokens that relate to the same logical event.

--
Annabelle Richard Backman
Amazon – Identity Services

---

From: Phil Hunt <[email-masked]>
Date: Mon, 23 Oct 2017 20:47:16 -0700

Annabelle,

I have a number of concerns with this proposal.

Profiling Independence / Keeping Event Payloads Independent

Indicating that extensions should be handled by profiles leads to more inter-operability issues and more importantly intrudes on the Event payload space by suggesting a sub-schema creates potential limitations and conflicts that may add to complexity later on. The current format allows a parser to discover and unload one or more JSON payloads which can each have independent structure.

General extensions

The proposal also rules out general purpose extensions not related to any specific event. Given the emergence of items like GPRD, I would not want to block the ability to add meta-data or other general purpose items. We can also anticipate some delivery scenarios where additional data might be required. Even though there is no current planned use, I see no good reason to rule this out.

Multiple Events From Different Families (vs. Multiple Events from a single family like RISC)

In our RISC session we discussed expressing multiple distinct RISC events in one SET. The discussion was that only one RISC event at a time. We did not discuss other event profiles. I don’t see a reason to rule out multi-events from different families at the SET level. Each profile is expressing slightly different things about the same event. 

I can forsee some cases where it is not clear which is the primary and which is the extension.  There may not be a clear winner.

A couple of examples (these are necessarily real…just possibilities):
* It is probably useful to be able to express simlar/overlapping events from different SET profiles in one SET.  For example a Backchannel Logout & a RISC session cancel event.
* SCIM may want to represent a single transaction as causing multiple state changes in an event (e.g. a password change causes multiple effects). Having to chase down multiple events and correlate by “txn” would be challenging in a multi-threaded/multi-node delivery system.  The SCIM list has not discussed this, but I would not want to block this capability.  IOW - Just because RISC does not want to express multiple events does not make this true for other profiles.
* We may wish to indicate a SCIM Password Reset was performed and a Logout/session cancellation is expressed at the same time.  The events are related but express different data.

Avoiding Confusion From Similar Events Originating from the Same Transaction

If events are sent separately, then more tracking of state (e.g. by txn) would be required to ensure similar events are not mistaken or handled as repeats. While txn provides useful audit analysis capability, I’m not sure it can be used in live or near-real time systems given distributed multi-node, multi-threading architectures.

Previous Discussion

I note that I originally raised having an attribute to designate primary event attribute to alleviate your concern, but this was not accepted. See: 
* https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html
* https://www.ietf.org/mail-archive/web/id-event/current/msg00140.html

The consensus, at least as I interpreted it is up to the receiver to figure this out based on the definitions it has for each event URI and the profiles they represent. IOW - RISC is free to limit that only one RISC event be expressed at a time.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
>  "iss": "https://scim.example.com <https://scim.example.com/>",
>   "aud": [
>     "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754 <https://scim.example.com/Feeds/98d52461fa5bbc879593b7754>",
>     "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7 <https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7>"
>   ],
>  
>   "event": {
>     "ref": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 <https://scim.example.com/Users/44f6142df96bd6ab61e7521d9>",
> _______________________________________________
> Id-event mailing list
> [email-masked] <mailto:[email-masked]>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=s5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=X8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=s5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=X8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=>

---

From: Mike Jones <[email-masked]>
Date: Tue, 24 Oct 2017 19:10:14 +0000

I agree with much of Phil’s rationale here.

It’s fine for some profiles to say that the “events” set must be a singleton.  That doesn’t have to be true for all events.  I think things are fine as-is.

                                                                -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, October 23, 2017 8:47 PM
To: Richard Backman, Annabelle <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Use cases for multiple events per SET?

Annabelle,

General extensions

Previous Discussion

Phil

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

On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

event

 "iss": "https://scim.example.com<https://scim.example.com/>",

  "event": {

Extensions

Aliases

Related Events

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

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 27 Oct 2017 00:35:32 +0000

Replies inline

From: Phil Hunt <[email-masked]>
Date: Monday, October 23, 2017 at 8:48 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Use cases for multiple events per SET?

Annabelle,

[richanna] As I said, I’m fine with defining an extension mechanism at the SET level, if people think it is necessary; I don’t have a strong opinion one way or the other, so I presented the simpler option (simpler in terms of amount of content in the SET spec). I think that would clear up any interoperability and reusability concerns. Add some text to the proposed event claim definition like:

The object MAY contain an "extensions" member, which if present is a JSON object whose keys are URIs identifying event extensions defined in Profiling Specifications, and whose values are JSON objects whose contents are defined in Profiling Specifications.

I’m not sure how mandating one or two members of the event payload is a meaningful intrusion. JWT defines 7 standard claims, and we seem to get along just fine with that. [/richanna]

General extensions

The proposal also rules out general purpose extensions not related to any specific event. Given the emergence of items like GPRD, I would not want to block the ability to add meta-data or other general purpose items. We can also anticipate some delivery scenarios where additional data might be required. Even though there is no current planned use, I see no good reason to rule this out.
[richanna] I think this is a good argument for defining the extension mechanism at the SET level; see above. [/richanna]

I can forsee some cases where it is not clear which is the primary and which is the extension.  There may not be a clear winner.
[richanna] Example? This defies my understanding of what the word “extension” means. It’s hard to argue that we can provide a standardized extension mechanism if event extensions are indistinguishable from primary events. [/richanna]

A couple of examples (these are necessarily real…just possibilities):
* It is probably useful to be able to express simlar/overlapping events from different SET profiles in one SET.  For example a Backchannel Logout & a RISC session cancel event.
[richanna] Why is it necessary or appropriate to include these events in the same SET? They are likely being generated by different systems at different times on the transmitter’s side, consumed by different systems on the receiver’s side, and possibly being transmitted over different event streams. I know the latter would be the case for us, as a receiver. Even if it’s not, is it burdensome to send these events separately? What value is gained in combining them? [/richanna]

* SCIM may want to represent a single transaction as causing multiple state changes in an event (e.g. a password change causes multiple effects). Having to chase down multiple events and correlate by “txn” would be challenging in a multi-threaded/multi-node delivery system.  The SCIM list has not discussed this, but I would not want to block this capability.  IOW - Just because RISC does not want to express multiple events does not make this true for other profiles.
[richanna] Yes, this is precisely why I raised the question: to find out if other profiles have a use case for this. Does SCIM have an actual use case, or a theoretical one? [/richanna]

* We may wish to indicate a SCIM Password Reset was performed and a Logout/session cancellation is expressed at the same time.  The events are related but express different data.
[richanna] Are a given transmitter/receiver pair guaranteed to use the same event stream for SCIM and Backchannel Logout? I think you’re going to run into interop problems if you make that assumption. [/richanna]

If events are sent separately, then more tracking of state (e.g. by txn) would be required to ensure similar events are not mistaken or handled as repeats. While txn provides useful audit analysis capability, I’m not sure it can be used in live or near-real time systems given distributed multi-node, multi-threading architectures.
[richanna] I don’t foresee txn correlation being an issue, but admittedly I’ve mostly thought about this from the RISC perspective, where there is a strong correlation between event volume and technical sophistication of the parties involved. What kind of event volume is expected for SCIM? What kind of confusion are you thinking of? Unless you’re going to say that events that are not transmitted in the same SET are not related, then receivers will have to be able to correlate in real time either way. [/richanna]

Previous Discussion

Phil

event

  "event": {

Extensions

Aliases

Related Events

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 29 Oct 2017 20:28:48 +0200

In that case, let's add text to that effect, e.g. we could add to the 
definition of the "events" claim:

Profiling specifications SHOULD define the allowed event statements, and 
MAY restrict their number. For example, some profiles may require this 
claim to contain only a single event statement.

Thanks,
	Yaron

On 24/10/17 22:10, Mike Jones wrote:
> It’s fine for some profiles to say that the “events” set must be a 
> singleton.  That doesn’t have to be true for all events.  I think things 
> are fine as-is.
> 
>                                                                  -- Mike
> 
> *From:* Id-event [mailto:[email-masked]] *On Behalf Of *Phil Hunt
> *Sent:* Monday, October 23, 2017 8:47 PM
> *To:* Richard Backman, Annabelle <[email-masked]>
> *Cc:* ID Events Mailing List <[email-masked]>
> *Subject:* Re: [Id-event] Use cases for multiple events per SET?
> 
> Annabelle,
> 
> Indicating that extensions should be handled by profiles leads to more 
> inter-operability issues and more importantly intrudes on the Event 
> payload space by suggesting a sub-schema creates potential limitations 
> and conflicts that may add to complexity later on. The current format 
> allows a parser to discover and unload one or more JSON payloads which 
> can each have independent structure.
> 
> General extensions
> 
> The proposal also rules out general purpose extensions not related to 
> any specific event. Given the emergence of items like GPRD, I would not 
> want to block the ability to add meta-data or other general purpose 
> items. We can also anticipate some delivery scenarios where additional 
> data might be required. Even though there is no current planned use, I 
> see no good reason to rule this out.
> 
> In our RISC session we discussed expressing multiple distinct RISC 
> events in one SET. The discussion was that only one RISC event at a 
> time. We did not discuss other event profiles. I don’t see a reason to 
> rule out multi-events from different families at the SET level. Each 
> profile is expressing slightly different things about the same event.
> 
> I can forsee some cases where it is not clear which is the primary and 
> which is the extension.  There may not be a clear winner.
> 
> * It is probably useful to be able to express simlar/overlapping events 
> from different SET profiles in one SET.  For example a Backchannel 
> Logout & a RISC session cancel event.
> 
> * SCIM may want to represent a single transaction as causing multiple 
> state changes in an event (e.g. a password change causes multiple 
> effects). Having to chase down multiple events and correlate by “txn” 
> would be challenging in a multi-threaded/multi-node delivery system. 
>   The SCIM list has not discussed this, but I would not want to block 
> this capability.  IOW - Just because RISC does not want to express 
> multiple events does not make this true for other profiles.
> 
> * We may wish to indicate a SCIM Password Reset was performed and a 
> Logout/session cancellation is expressed at the same time.  The events 
> are related but express different data.
> 
> If events are sent separately, then more tracking of state (e.g. by txn) 
> would be required to ensure similar events are not mistaken or handled 
> as repeats. While txn provides useful audit analysis capability, I’m not 
> sure it can be used in live or near-real time systems given distributed 
> multi-node, multi-threading architectures.
> 
> Previous Discussion
> 
> I note that I originally raised having an attribute to designate primary 
> event attribute to alleviate your concern, but this was not accepted. See:
> 
> The consensus, at least as I interpreted it is up to the receiver to 
> figure this out based on the definitions it has for each event URI and 
> the profiles they represent. IOW - RISC is free to limit that only one 
> RISC event be expressed at a time.
> 
> Phil
> 
> www.independentid.com <http://www.independentid.com>
> 
> [email-masked] <mailto:[email-masked]>
> 
>     On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     The current draft of the SET spec allows for expressing multiple
>     events within the same token, which introduces additional complexity
>     and room for ambiguous semantics. We’ve discussed this in the OIDF
>     RISC working group and the current consensus there is that RISC will
>     require that RISC events must be the only event in the SET, having
>     identified ways to clearly and easily support the handful of use
>     cases for multiple events per token that people have raised. With
>     that context in mind, I propose striking the definition of the
>     “events” claim from the Security Event Token spec, and replacing it
>     with the following definition for an “event” claim (singular):
> 
>     event
> 
>     A JSON object containing an "event_type" member whose value is a URI
>     representing a type of event defined in a Profiling Specification.
>     The object MAY otherwise be empty, or MAY contain additional members
>     as described by the Profiling Specification.
> 
>     Does anyone in the working group have use cases for SETs that cannot
>     be met by this proposed text? Within RISC, we identified three use
>     cases, with solutions outlined below:
> 
>     **
> 
>     *Extensions*
> 
>     Event extension mechanisms can be defined internal to the event
>     object. A simple approach would be to  define an “extensions” member
>     that is a list of event objects (or set resembling the “events”
>     claim as defined in the current spec). This has the advantage of
>     making it clear in the data structure that there is a single primary
>     event, with zero or more extensions. There is no room for confusion
>     over which event is primary, or if there is a primary event at all.
>     I would be fine with adding something like this to my proposed text,
>     if there is consensus that it is broadly useful.
> 
>     *Aliases*
> 
>     This use case was brought up in the context of migrating clients
>     from draft event names to standardized event names. In this case,
>     the event transmitter can transmit two tokens for the logical event,
>     one using the old name and another using the new name.
> 
>     *Related Events*
> 
>     The SET spec defines the txn claim as a means of correlating
>     independent tokens that relate to the same logical event.
> 
>     -- 
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>

---

From: Dick Hardt <[email-masked]>
Date: Sun, 29 Oct 2017 16:12:42 -0700

Phil:

In your examples for having a plurality of events, you use the word "may",
which leads me to question if a plurality of events is really required in
SET.

You posit that it will be difficult for a distributed system to correlate
multiple SETs with the same "txn", but the distributed system will
certainly need to correlate events on the same subject -- correlating
events on the same "txn" on the same subject seems fairly simple.

I think that a receiver will need to correlate multiple SEts on the same
subject, so having multiple events in a SET is redundant, and adds
complexity with no clear benefit that I can see.

An implementor may choose to send multiple SETs, or send a single SET with
multiple events, so a receiver will need to support both. I prefer we pick
one way and minimize the code paths, and we will need to support
correlating across multiple SETs, so that seems the best mechanism.

Let me know if there is something I missed in my logic.

/Dick

On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer <[email-masked]>
wrote:

>> inter-operability issues and more importantly intrudes on the Event payload
>> space by suggesting a sub-schema creates potential limitations and
>> conflicts that may add to complexity later on. The current format allows a
>> parser to discover and unload one or more JSON payloads which can each have
>> independent structure.
>>
>> General extensions
>>
>> The proposal also rules out general purpose extensions not related to any
>> specific event. Given the emergence of items like GPRD, I would not want to
>> block the ability to add meta-data or other general purpose items. We can
>> also anticipate some delivery scenarios where additional data might be
>> required. Even though there is no current planned use, I see no good reason
>> to rule this out.
>>
>> In our RISC session we discussed expressing multiple distinct RISC events
>> in one SET. The discussion was that only one RISC event at a time. We did
>> not discuss other event profiles. I don’t see a reason to rule out
>> multi-events from different families at the SET level. Each profile is
>> expressing slightly different things about the same event.
>>
>> from different SET profiles in one SET.  For example a Backchannel Logout &
>> a RISC session cancel event.
>>
>> state changes in an event (e.g. a password change causes multiple effects).
>> Having to chase down multiple events and correlate by “txn” would be
>> challenging in a multi-threaded/multi-node delivery system.   The SCIM list
>> has not discussed this, but I would not want to block this capability.  IOW
>> - Just because RISC does not want to express multiple events does not make
>> this true for other profiles.
>>
>> Logout/session cancellation is expressed at the same time.  The events are
>> related but express different data.
>>
>> would be required to ensure similar events are not mistaken or handled as
>> repeats. While txn provides useful audit analysis capability, I’m not sure
>> it can be used in live or near-real time systems given distributed
>> figure this out based on the definitions it has for each event URI and the
>> profiles they represent. IOW - RISC is free to limit that only one RISC
>> event be expressed at a time.
>>
>> Phil
>>
>>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivz
>> jWwlNKe4C_lLIGk&m=s5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibE
>> c&s=X8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=
>>
>>
>>

-- 
Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about
projects I am working on!

---

From: Phil Hunt <[email-masked]>
Date: Sun, 29 Oct 2017 17:25:46 -0700

I hope this answers your question.

My “may” was because I can’t see a reason why not. The question should be, what is the justification to make “events” singular?

There are many reasons for multiple events in a SET.  Some are good, some not so good. Some of the reasons...

1.  Multiple event payloads expressing statements about largely the *same*thing. For example, SCIM password reset AND RISC password reset.  A RISC Event and an OpenBanking Event. Is one a complement to the other?  Do they overlap or are they distinct?  
2.  Multiple events payloads expressing different statements about the same transaction - RISC Password Reset and RISC Session Cancel
3.  A new profile defines new event attributes to be added on to an existing event type (a pure extension) 

I think it is quite valid to allow 1 and 3.  2 could be limited by specific profiles like RISC if they want.

I am not in agreement that making event singular simplifies anything. For one is makes extensions complex (another nested JSON structure) and potentially conflicting. 

If the WG wants to block 1 and 2 above, then I believe we have to establish an event registry to ensure new Event profiles do not overlap to eliminate the need to express multiple events.

Phil

> On Oct 29, 2017, at 4:12 PM, Dick Hardt <[email-masked]> wrote:
> 
> Phil:
> 
> In your examples for having a plurality of events, you use the word "may", which leads me to question if a plurality of events is really required in SET.
> 
> You posit that it will be difficult for a distributed system to correlate multiple SETs with the same "txn", but the distributed system will certainly need to correlate events on the same subject -- correlating events on the same "txn" on the same subject seems fairly simple.
> 
> I think that a receiver will need to correlate multiple SEts on the same subject, so having multiple events in a SET is redundant, and adds complexity with no clear benefit that I can see.
> 
> An implementor may choose to send multiple SETs, or send a single SET with multiple events, so a receiver will need to support both. I prefer we pick one way and minimize the code paths, and we will need to support correlating across multiple SETs, so that seems the best mechanism.
> 
> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer <[email-masked] <mailto:[email-masked]>> wrote:
> In that case, let's add text to that effect, e.g. we could add to the definition of the "events" claim:
> 
> Profiling specifications SHOULD define the allowed event statements, and MAY restrict their number. For example, some profiles may require this claim to contain only a single event statement.
> 
> Thanks,
>         Yaron
> 
> *From:* Id-event [mailto:[email-masked] <mailto:[email-masked]>] *On Behalf Of *Phil Hunt
> *To:* Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>>
> *Cc:* ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
> * https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00406.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=S3sMViqMvEgnwGbJwOQNycrOyr7Sefpq_MoFOKcEeCE&e=>
> 
> * https://www.ietf.org/mail-archive/web/id-event/current/msg00140.html <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00140.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=Gy9gyRoIIta-cShV7bN161ay4yE6r9G1_Aa_NeBnylg&e=>
> 
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=9NP5namg6rIVzwun9c-1q0whsyXwSvtHB0f2dKkfCX8&e=> <http://www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=9NP5namg6rIVzwun9c-1q0whsyXwSvtHB0f2dKkfCX8&e=>>
> 
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> 
>     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> 
>       "iss": "https://scim.example.com <https://scim.example.com/> <https://scim.example.com/ <https://scim.example.com/>>",
> 
>        "aud": [
> 
>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> https://www.ietf.org/mailman/listinfo/id-event <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=WrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=>
> 
> 
> https://www.ietf.org/mailman/listinfo/id-event <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=WrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=>
> 
> 
> 
> -- 
> Subscribe to the HARDTWARE <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=LYN72GgKVhHsT6tAqBe-eMoWMvy_7dfFn1uZ0HK6YuQ&e=> mail list to learn about projects I am working on!
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=WrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&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=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=WrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=>

---

From: Dick Hardt <[email-masked]>
Date: Sun, 29 Oct 2017 17:33:28 -0700

On Sun, Oct 29, 2017 at 5:25 PM, Phil Hunt <[email-masked]> wrote:

> My “may” was because I can’t see a reason why not. The question should be,
> what is the justification to make “events” singular?
>

I strongly disagree. Added complexity should be justified. A singular event
is less complex than a plurality of events. The complexity of plurality in
the SET needs to be offset by simplicity somewhere else.

> 1.  Multiple event payloads expressing statements about largely the
> *same*thing. For example, SCIM password reset AND RISC password reset.  A
> RISC Event and an OpenBanking Event. Is one a complement to the other?  Do
> they overlap or are they distinct?
>

So will it be required that these MUST always be in the same SET? If we
allow them to be different SETs, then an implementor is needing to support
both mechanisms.

> 2.  Multiple events payloads expressing different statements about the
> same transaction - RISC Password Reset and RISC Session Cancel
>

See above.

> existing event type (a pure extension)

I don't know why this would not be additional attributes in the same event.

>
> I think it is quite valid to allow 1 and 3.  2 could be limited by
> specific profiles like RISC if they want.
>
> I am not in agreement that making event singular simplifies anything. For
> one is makes extensions complex (another nested JSON structure) and
> potentially conflicting.
>

I'm confused why you would not extend the event object. Adding an
additional event as an extension seems very complex and non-intuitive.
Perhaps I am missing something. Do you have an example to clarify?

>
> If the WG wants to block 1 and 2 above, then I believe we have to
> establish an event registry to ensure new Event profiles do not overlap to
> eliminate the need to express multiple events.
>

Each event has a URI already does it not? We already need to uniquely
identify event semantics.

> www.independentid.com
> [email-masked]
>>> want to block the ability to add meta-data or other general purpose items.
>>> We can also anticipate some delivery scenarios where additional data might
>>> be required. Even though there is no current planned use, I see no good
>>> reason to rule this out.
>>>
>>> events in one SET. The discussion was that only one RISC event at a time.
>>> We did not discuss other event profiles. I don’t see a reason to rule out
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00406.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=S3sMViqMvEgnwGbJwOQNycrOyr7Sefpq_MoFOKcEeCE&e=>
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00140.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=Gy9gyRoIIta-cShV7bN161ay4yE6r9G1_Aa_NeBnylg&e=>
>>>
>>> www.independentid.com
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=9NP5namg6rIVzwun9c-1q0whsyXwSvtHB0f2dKkfCX8&e=>
>>>  <http://www.independentid.com
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=9NP5namg6rIVzwun9c-1q0whsyXwSvtHB0f2dKkfCX8&e=>
>>> >
>>>
>>>     https://urldefense.proofpoint.com/v2/url?u=https-
>>> 3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&
>>> c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
>>> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=s5byBe5KANnGVu
>>> Ab1mAupEGoJn8XG5JIUUwWGFSibEc&s=X8oRSq3IzlF7jiRAeZhXpR3eVI0I
>>> 58ZFd4eEZfgyoIY&e=
>>>
>>>
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=WrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=>
>>>
>>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=WrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=>
>>
>
>
>
> --
> Subscribe to the HARDTWARE
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=LYN72GgKVhHsT6tAqBe-eMoWMvy_7dfFn1uZ0HK6YuQ&e=>
>  mail list to learn about projects I am working on!
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-
> 2tDkn31Auxuruib9KATkRlQG1iw&s=WrMuQRwLV802iMQ4wYB1f2rFUGu4zb
> hcW001fK02EXs&e=
>
>
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 30 Oct 2017 15:57:07 +0000

Replies inline.

Identity Services

From: Phil Hunt <[email-masked]>
Date: Sunday, October 29, 2017 at 5:25 PM
To: Dick Hardt <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, Mike Jones <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Use cases for multiple events per SET?

My “may” was because I can’t see a reason why not. The question should be, what is the justification to make “events” singular?
[richanna]The singular “event” claim has clearer semantics and is easier to process. We should opt for easier solutions unless there are use cases that require more complexity.[/richanna]

1.  Multiple event payloads expressing statements about largely the *same*thing. For example, SCIM password reset AND RISC password reset.  A RISC Event and an OpenBanking Event. Is one a complement to the other?  Do they overlap or are they distinct?
[richanna]Copy/pasted from my earlier email:
Why is it necessary or appropriate to include these events in the same SET? They are likely being generated by different systems at different times on the transmitter’s side, consumed by different systems on the receiver’s side, and possibly being transmitted over different event streams. I know the latter would be the case for us, as a receiver. Even if it’s not, is it burdensome to send these events separately? What value is gained in combining them?

Additionally, since the signature is over the SET and not the event objects, Receivers independently route separate events from a single token without either losing the ability to verify the authenticity of the event or sharing all information in the SET with every system handling any event in the token.[/richanna]

2.  Multiple events payloads expressing different statements about the same transaction - RISC Password Reset and RISC Session Cancel
[richanna]Same as above[/richanna]

3.  A new profile defines new event attributes to be added on to an existing event type (a pure extension)
[richanna]I have suggested a way to support extensions within an event body, multiple times now. If you see problems with it, please point them out.[/richanna]

I am not in agreement that making event singular simplifies anything. For one is makes extensions complex (another nested JSON structure) and potentially conflicting.
[richanna]
Ways that multiple-event SETs are more complicated:

  1.  It results in a more complex structure for the single event use case, which I think we all agree is the majority use case.
  2.  Multiple-event SETs have ambiguous semantics. The presence of two events A and B in the same SET could mean any of:

     *   They are related to the same logical event (i.e. the same thing as if they were from different SETs that have a common txn).
     *   A is an extension of B.
     *   B is an extension of A.
     *   They are aliases for one another.
     *   They are not actually related to one another in any way.

  1.  Claim semantics become harder to define, as different profiles may want to use the same claims in different ways.

If the WG wants to block 1 and 2 above, then I believe we have to establish an event registry to ensure new Event profiles do not overlap to eliminate the need to express multiple events.
[richanna]I’m not sure what you mean by this. Are you referring to event names? Those are already defined by the spec to be URIs.[/richanna]
Phil

On Oct 29, 2017, at 4:12 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

Phil:

/Dick

On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:
In that case, let's add text to that effect, e.g. we could add to the definition of the "events" claim:

Thanks,
        Yaron

                                                                 -- Mike

*From:* Id-event [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *Phil Hunt
*Sent:* Monday, October 23, 2017 8:47 PM
*To:* Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>
*Cc:* ID Events Mailing List <[email-masked]<mailto:[email-masked]>>
*Subject:* Re: [Id-event] Use cases for multiple events per SET?

Annabelle,

General extensions

Previous Discussion

* https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00406.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=S3sMViqMvEgnwGbJwOQNycrOyr7Sefpq_MoFOKcEeCE&e=>

* https://www.ietf.org/mail-archive/web/id-event/current/msg00140.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00140.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=Gy9gyRoIIta-cShV7bN161ay4yE6r9G1_Aa_NeBnylg&e=>

Phil

@independentid

www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=9NP5namg6rIVzwun9c-1q0whsyXwSvtHB0f2dKkfCX8&e=> <http://www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=9NP5namg6rIVzwun9c-1q0whsyXwSvtHB0f2dKkfCX8&e=>>

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

    On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle
    <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    event

    Here is the example SET from section 2.3, rewritten with this change
    mind:

    {

       "iat": 1458496404,

      "iss": "https://scim.example.com<https://scim.example.com/> <https://scim.example.com/>",

       "aud": [

       ],

       "event": {

       }

    }

    **

    *Extensions*

    *Aliases*

    *Related Events*

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

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=WrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=WrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=>

--
Subscribe to the HARDTWARE<https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=LYN72GgKVhHsT6tAqBe-eMoWMvy_7dfFn1uZ0HK6YuQ&e=> mail list to learn about projects I am working on!
_______________________________________________
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=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=WrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=

---

From: Phil Hunt <[email-masked]>
Date: Mon, 30 Oct 2017 12:09:17 -0700

Annabelle/Dick,

Thanks for the comments. I think we need to examine the consequences of the proposal in JSON.

As I stated, what causes most of the issue is the proposed extension mechanism in the payload (possibly using events in a recursive way). Does it follow the old format or the new?

Let’s  consider a use case where we have an identity management system that uses SCIM, but the SCIM system is also the underlying data store for Connect.  A Password reset might generate the following event which has an extension (conveying reset count) AND overlapping statement from RISC.  BOTH of which might be important to a similar receiver using SCIM and OIDC.  

The 03 spec currently would allow:

{
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "iss": "https://scim.example.com",
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
   ],
   "events": {
     "urn:ietf:params:scim:event:passwordReset":
       { "id":"44f6142df96bd6ab61e7521d9"},
     "https://example.com/scim/event/passwordResetExt":
       { "resetAttempts":5},
     "http://schemas.openid.net/secevent/risc/event-type/\
       account-credential-change-required": {
         “sub”:”7375626A656374”,
         “iss”:"https://idp.example.com/"
       }
  }
}

In the above - each payload is a ‘peer' and issued without preference by the transmitter. The receiver can assign priority in its own context if that matters.

The new proposal:

{
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "iss": "https://scim.example.com",
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
   ],
   "event": {
     “event_type”:"urn:ietf:params:scim:event:passwordReset”,
     "id":”44f6142df96bd6ab61e7521d9”,
     “events”:{
     ->note …is this the old or new structure? <-
       "https://example.com/scim/event/passwordResetExt":
         { "resetAttempts":5},
       "http://schemas.openid.net/secevent/risc/event-type/\
         account-credential-change-required": {
         “sub”:”7375626A656374”,
         “iss”:"https://idp.example.com/"
       }
     }
   }    
}

In the above, sub-events or extensions have a different format. The same complaint about the original stands.

*OR* (if the receiver cares about RISC more).  Note that this leads to a triple nested structure.

{
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "iss": "https://scim.example.com",
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
   ],
   "event": {
     “event_type”:"http://schemas.openid.net/secevent/risc/event-type/\
             account-credential-change-required”,
      “sub”:”7375626A656374”,
      “iss”:"https://idp.example.com/“,
      “events”:{
        "urn:ietf:params:scim:event:passwordReset":
        { 
          "id":”44f6142df96bd6ab61e7521d9”,
          “events”:{
             "https://example.com/scim/event/passwordResetExt":
               { "resetAttempts":5},  
          }      
        }
      }     
   }
}

In the above, the extension is placed inside the event it extends. It follows the old format (or should it follow the new?)
*OR* Following the top layer pattern of singular event  Note that this leads to a triple nested structure.

{
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "iss": "https://scim.example.com",
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
   ],
   "event": {
     “event_type”:"http://schemas.openid.net/secevent/risc/event-type/\
             account-credential-change-required”,
      “sub”:”7375626A656374”,
      “iss”:"https://idp.example.com/“,
      “event”:{
        “event_type”:"urn:ietf:params:scim:event:passwordReset”,
        "id":”44f6142df96bd6ab61e7521d9”,
        “event”:{
          “event_type”:"https://example.com/scim/event/passwordResetExt”,
          "resetAttempts":5 
        }
      }     
   }
}

This format follows the proposed singular event format recursively and is 3 layers deep. Note that the parser has to continue to search the document for things that aren’t there as it has to stop when no “event” attribute is found rather than iterate over an array.

Phil

> On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> Replies inline.
>  
> -- 
> From: Phil Hunt <[email-masked] <mailto:[email-masked]>>
> To: Dick Hardt <[email-masked] <mailto:[email-masked]>>
> Cc: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, Mike Jones <[email-masked] <mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
> It results in a more complex structure for the single event use case, which I think we all agree is the majority use case.
> Multiple-event SETs have ambiguous semantics. The presence of two events A and B in the same SET could mean any of:
> They are related to the same logical event (i.e. the same thing as if they were from different SETs that have a common txn).
> A is an extension of B.
> B is an extension of A.
> They are aliases for one another.
> They are not actually related to one another in any way.
> Claim semantics become harder to define, as different profiles may want to use the same claims in different ways.
>  
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=U-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=KBwKPFnqY_Q95CTA__WGCYGTxrD7AGCxueoPXnKEUT0&e=>
>> On Oct 29, 2017, at 4:12 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Phil:
>>  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=U-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=rvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm46QSz0&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=U-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=rvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm46QSz0&e=>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 30 Oct 2017 14:22:26 -0700

Hi Phil

Correct me if I am misunderstanding, but there is a RISC profile event

"http://schemas.openid.net/secevent/risc/event-type/
<http://schemas.openid.net/secevent/risc/event-type/%5C>account-credential-change-required”

and an SCIM profile event

"https://example.com/scim/event/passwordResetExt”

I'm suggesting that two different events would be sent. Embedding one in
the other does not make sense.

Also, I think it is simpler to have event_type be at the same level as event

{
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "iss": "https://scim.example.com",
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
   ],
   "event_type": "https://example.com/scim/event/passwordResetExt",
   "event": {
         "id":"44f6142df96bd6ab61e7521d9",
         "resetAttempts":5
       }
}

{
   "event_type": "
http://schemas.openid.net/secevent/risc/event-type/account-credential-change-required
",

On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt <[email-masked]> wrote:

> As I stated, what causes most of the issue is the proposed extension
> mechanism in the payload (possibly using events in a recursive way). Does
> it follow the old format or the new?
>
> Let’s  consider a use case where we have an identity management system
> that uses SCIM, but the SCIM system is also the underlying data store for
> Connect.  A Password reset might generate the following event which has an
> extension (conveying reset count) AND overlapping statement from RISC.
> BOTH of which might be important to a similar receiver using SCIM and OIDC.
>
>
> *The 03 spec currently would allow:*
>
> {
> *The new proposal:*
> **OR* (if the receiver cares about RISC more).  Note that this leads to a triple nested structure.*
>
>
> {
> In the above, the extension is placed inside the event it extends. It
> follows the old format (or should it follow the new?)
>
> **OR* Following the top layer pattern of singular event  Note that this leads to a triple nested structure.*
>
>
> {
> This format follows the proposed singular event format recursively and is
> 3 layers deep. Note that the parser has to continue to search the document
> for things that aren’t there as it has to stop when no “event” attribute is
> found rather than iterate over an array.
>
> Phil
>
> *From: *Phil Hunt <[email-masked]>
> *Date: *Sunday, October 29, 2017 at 5:25 PM
> *To: *Dick Hardt <[email-masked]>
> *Cc: *Yaron Sheffer <[email-masked]>, Mike Jones <
> [email-masked]>, "Richard Backman, Annabelle" <
> [email-masked]>, ID Events Mailing List <[email-masked]>
> *Subject: *Re: [Id-event] Use cases for multiple events per SET?
>
> [richanna]The singular “event” claim has clearer semantics and is easier
> to process. We should opt for easier solutions unless there are use cases
> that require more complexity.[/richanna]
>
> Why is it necessary or appropriate to include these events in the same
> SET? They are likely being generated by different systems at different
> times on the transmitter’s side, consumed by different systems on the
> receiver’s side, and possibly being transmitted over different event
> streams. I know the latter would be the case for us, as a receiver. Even if
> it’s not, is it burdensome to send these events separately? What value is
> gained in combining them?
>
> Additionally, since the signature is over the SET and not the event
> objects, Receivers independently route separate events from a single token
> without either losing the ability to verify the authenticity of the event
> or sharing all information in the SET with every system handling any event
> in the token.[/richanna]
>
> [richanna]I have suggested a way to support extensions within an event
> body, multiple times now. If you see problems with it, please point them
> out.[/richanna]
>
>    1. It results in a more complex structure for the single event use
>    case, which I think we all agree is the majority use case.
>    2. Multiple-event SETs have ambiguous semantics. The presence of two
>    events A and B in the same SET could mean any of:
>
>
>    1. They are related to the same logical event (i.e. the same thing as
>       if they were from different SETs that have a common txn).
>       2. A is an extension of B.
>       3. B is an extension of A.
>       4. They are aliases for one another.
>       5. They are not actually related to one another in any way.
>
>
>    1. Claim semantics become harder to define, as different profiles may
>    want to use the same claims in different ways.
>
>
> [richanna]I’m not sure what you mean by this. Are you referring to event
> names? Those are already defined by the spec to be URIs.[/richanna]
> Phil
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=U-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=KBwKPFnqY_Q95CTA__WGCYGTxrD7AGCxueoPXnKEUT0&e=>
> [email-masked]
>
>
> 3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=
> s5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=
> X8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=
>
>
>
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=U-
> a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=rvdrtI7rYNRAnqZDltCwBAZVHKp-
> MJ20ui2nm46QSz0&e=
>
>
>

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 30 Oct 2017 14:29:55 -0700

I started writing something very similar. What Dick says. I totally support
single events at this point, even though at the beginning I was challenging
this approach. We do have to formally define an extension mechanism.

Extension attributes could be simply merged into the target event as in
Dick's example.

Or, I think Annabelle suggested (if I understood correctly) that we could
have a defined "extensions" attribute which is a dictionary with keys being
extension URIs and values being name/value pairs. In this case the first
event would look something like:
{
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "iss": "https://scim.example.com",
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
   ],
   "event_type": "https://example.com/scim/event/passwordResetExt",
   "event": {
         "id":"44f6142df96bd6ab61e7521d9",
         "extensions": {
           "https://example.com/scim/event/passwordResetExt”: {
             "resetAttempts":5,
           }
         }
       }
}

Marius

On Mon, Oct 30, 2017 at 2:22 PM, Dick Hardt <[email-masked]> wrote:

> "http://schemas.openid.net/secevent/risc/event-type/ <http://schemas.openid.net/secevent/risc/event-type/%5C>account-credential-change-required”
>
>
>    "event_type": "http://schemas.openid.net/secevent/risc/event-type/
> account-credential-change-required",
>    "event": {
>        “sub”:”7375626A656374”,
>> My “may” was because I can’t see a reason why not. The question should
>> be, what is the justification to make “events” singular?
>> In your examples for having a plurality of events, you use the word
>> "may", which leads me to question if a plurality of events is really
>> required in SET.
>>
>> An implementor may choose to send multiple SETs, or send a single SET
>> with multiple events, so a receiver will need to support both. I prefer we
>> pick one way and minimize the code paths, and we will need to support
>> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCg
>> aWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPE
>> ivzjWwlNKe4C_lLIGk&m=s5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFS
>> ibEc&s=X8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=
>>
>>
>>
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1i
>> w&s=WrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=
>>
>>
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=U-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGie
>> c&s=rvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm46QSz0&e=
>>
>>
>>
>
>
> --
> Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn
> about projects I am working on!
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 30 Oct 2017 14:41:59 -0700

Inline...

Phil

> On Oct 30, 2017, at 2:22 PM, Dick Hardt <[email-masked]> wrote:
> 
> Hi Phil
> 
> "http://schemas.openid.net/secevent/risc/event-type/account-credential-change-required”
> 
> I'm suggesting that two different events would be sent. Embedding one in the other does not make sense.
<ph>It is a hypothetical example. Just because you disagree on this does not mean others are not valid. 

I just picked overlapping proposals that have different meaning (but not the same) to illustrate the difference from issuing a single set with different events. 

As I have stated this is very different from asserting multiple distinct events in one SET. 
> Also, I think it is simpler to have event_type be at the same level as event

<ph>may be. I was working from Annabelle's proposed format. 
>    "event_type": "http://schemas.openid.net/secevent/risc/event-type/account-credential-change-required",
>    "event": {
>        “sub”:”7375626A656374”,
>>>>> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer <[email-masked]> wrote:
>>>> Subscribe to the HARDTWARE mail list to learn about projects I am working on!
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=U-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=rvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm46QSz0&e=
>> 
> 
> 
> 
> -- 
> Subscribe to the HARDTWARE mail list to learn about projects I am working on!
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=Oe0qfLEX83vtXM7Wl2cYBe-Gg1DVPjhXjVJkfhVRzwc&e=

---

From: Mike Jones <[email-masked]>
Date: Tue, 31 Oct 2017 19:48:57 +0000

It’s hard for me to even express my level of frustration with the recent attempts to once again redesign the SecEvent Token spec.  We’ve been at this for multiple years because people keep trying to revisit decisions that were long ago made by consensus.  It’s been stable for over a year and the majority of WGLC respondents said some variant of “Works for me – ship it!”

There’s not sufficient justification to try to undo consensus positions that have been debated and affirmed over and over.  Countenancing wholesale changes at this late date is counterproductive in the extreme!

It’s far better than good enough as-is.  In my experience, if we start redesigning it, it will result in another year’s delay.  It does something simple and useful.  Please, let’s just ship it, so people can rely on it.

                                                       -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked]]
Sent: Monday, October 30, 2017 2:42 PM
To: Dick Hardt <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; Mike Jones <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Use cases for multiple events per SET?

Inline...

Phil

On Oct 30, 2017, at 2:22 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
Hi Phil

"http://schemas.openid.net/secevent/risc/event-type/<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_secevent_risc_event-2Dtype_-255C&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=25l09sH8YV42xzgU-CXSg8xH9tvyDJz40tCRjFalhkw&e=>account-credential-change-required”

{

{
   "event_type": "http://schemas.openid.net/secevent/risc/event-type/account-credential-change-required<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_secevent_risc_event-2Dtype_account-2Dcredential-2Dchange-2Drequired&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=nQy9ezPRjDGdvRTCaiDti4OHelH3DKgUCTKjF2GQ-so&e=>",

On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Annabelle/Dick,

{

  "iat": 1458496025,

  "aud": [

   ],

   "events": {

       { "resetAttempts":5},

     "http://schemas.openid.net/secevent/risc/event-type/\<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_secevent_risc_event-2Dtype_-255C&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=25l09sH8YV42xzgU-CXSg8xH9tvyDJz40tCRjFalhkw&e=>
       account-credential-change-required": {

         “sub”:”7375626A656374”,

       }

  }

}

The new proposal:

{

  "iat": 1458496025,

  "aud": [

   ],

   "event": {

     “events”:{

         { "resetAttempts":5},

       "http://schemas.openid.net/secevent/risc/event-type/\<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_secevent_risc_event-2Dtype_-255C&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=25l09sH8YV42xzgU-CXSg8xH9tvyDJz40tCRjFalhkw&e=>
         account-credential-change-required": {

         “sub”:”7375626A656374”,

       }

     }

   }

}

{

  "iat": 1458496025,

  "aud": [

   ],

   "event": {

     “event_type”:"http://schemas.openid.net/secevent/risc/event-type/\<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_secevent_risc_event-2Dtype_-255C&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=25l09sH8YV42xzgU-CXSg8xH9tvyDJz40tCRjFalhkw&e=>

      “sub”:”7375626A656374”,

      “events”:{

        {

          “events”:{

               { "resetAttempts":5},

          }

        }

      }

   }

}

{

  "iat": 1458496025,

  "aud": [

   ],

   "event": {

     “event_type”:"http://schemas.openid.net/secevent/risc/event-type/\<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_secevent_risc_event-2Dtype_-255C&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=25l09sH8YV42xzgU-CXSg8xH9tvyDJz40tCRjFalhkw&e=>

      “sub”:”7375626A656374”,

      “event”:{

        “event”:{

          "resetAttempts":5

        }

      }

   }

}

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=9sYhgpEzb7xPlQFmCCXNmHo6fQN9IBu-SHJamg_B4Hs&e=>
[email-masked]<mailto:[email-masked]>

On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

Replies inline.

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Sunday, October 29, 2017 at 5:25 PM
To: Dick Hardt <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, Mike Jones <[email-masked]<mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, ID Events Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Use cases for multiple events per SET?

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=U-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=KBwKPFnqY_Q95CTA__WGCYGTxrD7AGCxueoPXnKEUT0&e=>
[email-masked]<mailto:[email-masked]>

Phil:

/Dick

Thanks,
        Yaron

                                                                 -- Mike

Annabelle,

General extensions

Previous Discussion

Phil

@independentid

    event

    {

       "iat": 1458496404,

       "aud": [

       ],

       "event": {

       }

    }

    **

    *Extensions*

    *Aliases*

    *Related Events*

--
Subscribe to the HARDTWARE<https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=wtgD3Np0vyhLdpEwUiqsf4ItiwA3Om7Grob70Lx0r3k&e=> mail list to learn about projects I am working on!
_______________________________________________
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=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=Oe0qfLEX83vtXM7Wl2cYBe-Gg1DVPjhXjVJkfhVRzwc&e=

---

From: Dick Hardt <[email-masked]>
Date: Tue, 31 Oct 2017 21:37:05 -0700

Mike

As you well know, many people in a WG don't look closely at a specification
until last call is made. Additionally, we are coming up on only the 3rd WG
meeting. The WG has not existed for very long. While some of the
participants have been working on this for a while, many have not, and we
are looking for consensus across the WG.

Since SecEvent is a framework that we expect to be profiled, I feel it is
important to ensure that SecEvent specifications are easy for a variety of
profiles to adopt, and that the semantics make sense. I also think that
properties that are specific to a profile should be left to that profile
and not be included in SecEvent.

Since this is a framework, it is expected that as different groups profile
it, there will be additional feedback.

Specifically, as a participant in the RISC profile of SET, a number of
issues in SET have surfaced as the RISC WG has looked at how to use the SET.

As for SET being stable for over a year, there have been a number of
changes to SET since then. I also don't think there was consensus. Before
the WG was formed, I and several others had expressed concern on the design
of SET when Phil presented it at an IIW session.

As to taking another year, I am hopeful we can resolve the remaining issues
in SET and publish a new draft for last call. I do not think we will need
to wait for another WG meeting to ask for last call.

We also have a number of other documents that are not in last call, and we
don't have a WG adopted draft yet for management. So there are still a
number of documents to work through before we have all the bits for someone
to work with.

I do think we have been making good progress since the last IETF meeting,
and I am hopeful we can keep up this momentum and finalize all the
documents in a timely manner.

/Dick

On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones <[email-masked]>
wrote:

> It’s hard for me to even express my level of frustration with the recent
> attempts to once again redesign the SecEvent Token spec.  We’ve been at
> this for multiple years because people keep trying to revisit decisions
> that were long ago made by consensus.  It’s been stable for over a year and
> the majority of WGLC respondents said some variant of “Works for me – ship
> it!”
>
>
>
> There’s not sufficient justification to try to undo consensus positions
> that have been debated and affirmed over and over.  Countenancing wholesale
> changes at this late date is counterproductive in the extreme!
>
>
>
> It’s far better than good enough as-is.  In my experience, if we start
> redesigning it, it will result in another year’s delay.  It does something
> simple and useful.  Please, let’s just ship it, so people can rely on it.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Phil Hunt (IDM) [mailto:[email-masked]]
> *Sent:* Monday, October 30, 2017 2:42 PM
> *To:* Dick Hardt <[email-masked]>
> *Cc:* Yaron Sheffer <[email-masked]>; Richard Backman, Annabelle <
> [email-masked]>; Mike Jones <[email-masked]>; ID Events
> Mailing List <[email-masked]>
>
> "http://schemas.openid.net/secevent/risc/event-type/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_secevent_risc_event-2Dtype_-255C&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=25l09sH8YV42xzgU-CXSg8xH9tvyDJz40tCRjFalhkw&e=>account-credential-change-required”
>
>
>
> I just picked overlapping proposals that have different meaning (but not
> the same) to illustrate the difference from issuing a single set with
> different events.
>
>
>
> account-credential-change-required
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_secevent_risc_event-2Dtype_account-2Dcredential-2Dchange-2Drequired&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=nQy9ezPRjDGdvRTCaiDti4OHelH3DKgUCTKjF2GQ-so&e=>
> ",
>
>    "event": {
>
>        “sub”:”7375626A656374”,
>
>      "http://schemas.openid.net/secevent/risc/event-type/\ <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_secevent_risc_event-2Dtype_-255C&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=25l09sH8YV42xzgU-CXSg8xH9tvyDJz40tCRjFalhkw&e=>
>        "http://schemas.openid.net/secevent/risc/event-type/\ <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_secevent_risc_event-2Dtype_-255C&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=25l09sH8YV42xzgU-CXSg8xH9tvyDJz40tCRjFalhkw&e=>
>      “event_type”:"http://schemas.openid.net/secevent/risc/event-type/\ <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_secevent_risc_event-2Dtype_-255C&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=25l09sH8YV42xzgU-CXSg8xH9tvyDJz40tCRjFalhkw&e=>
>
>      “event_type”:"http://schemas.openid.net/secevent/risc/event-type/\ <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_secevent_risc_event-2Dtype_-255C&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=25l09sH8YV42xzgU-CXSg8xH9tvyDJz40tCRjFalhkw&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=9sYhgpEzb7xPlQFmCCXNmHo6fQN9IBu-SHJamg_B4Hs&e=>
> [email-masked]
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=wtgD3Np0vyhLdpEwUiqsf4ItiwA3Om7Grob70Lx0r3k&e=>
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=iyVnrZmr9_
> uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=Oe0qfLEX83vtXM7Wl2cYBe-
> Gg1DVPjhXjVJkfhVRzwc&e=
>
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 1 Nov 2017 04:42:14 +0000

I hear you on the fact that different people have joined the effort at different times.  That’s a normal process as an effort builds momentum.  I get that not everyone was there when previous consensus calls were taken.

I should note that I have specific technical objections to the specific proposed changes being discussed as well.  Currently all events in the set have the same syntax.  The proposals, as I understand them, revert us to a state where there’s a “primary” and “secondary” events, with different syntax for the two classes.  That’s needlessly more complicated, adding no actual value.

                                                                -- Mike

From: Dick Hardt [mailto:[email-masked]]
Sent: Tuesday, October 31, 2017 9:37 PM
To: Mike Jones <[email-masked]>
Cc: Phil Hunt (IDM) <[email-masked]>; Yaron Sheffer <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Use cases for multiple events per SET?

Mike

As you well know, many people in a WG don't look closely at a specification until last call is made. Additionally, we are coming up on only the 3rd WG meeting. The WG has not existed for very long. While some of the participants have been working on this for a while, many have not, and we are looking for consensus across the WG.

Since SecEvent is a framework that we expect to be profiled, I feel it is important to ensure that SecEvent specifications are easy for a variety of profiles to adopt, and that the semantics make sense. I also think that properties that are specific to a profile should be left to that profile and not be included in SecEvent.

Since this is a framework, it is expected that as different groups profile it, there will be additional feedback.

Specifically, as a participant in the RISC profile of SET, a number of issues in SET have surfaced as the RISC WG has looked at how to use the SET.

As for SET being stable for over a year, there have been a number of changes to SET since then. I also don't think there was consensus. Before the WG was formed, I and several others had expressed concern on the design of SET when Phil presented it at an IIW session.

As to taking another year, I am hopeful we can resolve the remaining issues in SET and publish a new draft for last call. I do not think we will need to wait for another WG meeting to ask for last call.

We also have a number of other documents that are not in last call, and we don't have a WG adopted draft yet for management. So there are still a number of documents to work through before we have all the bits for someone to work with.

I do think we have been making good progress since the last IETF meeting, and I am hopeful we can keep up this momentum and finalize all the documents in a timely manner.

/Dick

On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
It’s hard for me to even express my level of frustration with the recent attempts to once again redesign the SecEvent Token spec.  We’ve been at this for multiple years because people keep trying to revisit decisions that were long ago made by consensus.  It’s been stable for over a year and the majority of WGLC respondents said some variant of “Works for me – ship it!”

                                                       -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, October 30, 2017 2:42 PM
To: Dick Hardt <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>; ID Events Mailing List <[email-masked]<mailto:[email-masked]>>

Inline...

Phil

{

{

{

  "iat": 1458496025,

  "aud": [

   ],

   "events": {

       { "resetAttempts":5},

         “sub”:”7375626A656374”,

       }

  }

}

The new proposal:

{

  "iat": 1458496025,

  "aud": [

   ],

   "event": {

     “events”:{

         { "resetAttempts":5},

         “sub”:”7375626A656374”,

       }

     }

   }

}

{

  "iat": 1458496025,

  "aud": [

   ],

   "event": {

      “sub”:”7375626A656374”,

      “events”:{

        {

          “events”:{

               { "resetAttempts":5},

          }

        }

      }

   }

}

{

  "iat": 1458496025,

  "aud": [

   ],

   "event": {

      “sub”:”7375626A656374”,

      “event”:{

        “event”:{

          "resetAttempts":5

        }

      }

   }

}

Phil

Replies inline.

Phil:

/Dick

Thanks,
        Yaron

                                                                 -- Mike

Annabelle,

General extensions

Previous Discussion

Phil

@independentid

    event

    {

       "iat": 1458496404,

       "aud": [

       ],

       "event": {

       }

    }

    **

    *Extensions*

    *Aliases*

    *Related Events*

--
Subscribe to the HARDTWARE<http://hardtware.com/> mail list to learn about projects I am working on!

---

From: Dick Hardt <[email-masked]>
Date: Tue, 31 Oct 2017 21:51:46 -0700

Please direct me to a proposal that has a "primary" and "secondary" events.
I agree that is undesirable. I would also encourage to engage in the
discussions so that we can drive clarity and simplicity.

I think the proposal is that there is one event per SET.

I think having more than one event per SET adds complexity as a receiver
must deal with receiving correlated events in one SET as well as correlated
events in the same SET.

/Dick

On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones <[email-masked]>
wrote:

> I hear you on the fact that different people have joined the effort at
> different times.  That’s a normal process as an effort builds momentum.  I
> get that not everyone was there when previous consensus calls were taken.
>
>
>
> I should note that I have specific technical objections to the specific
> proposed changes being discussed as well.  Currently all events in the set
> have the same syntax.  The proposals, as I understand them, revert us to a
> state where there’s a “primary” and “secondary” events, with different
> syntax for the two classes.  That’s needlessly more complicated, adding no
> actual value.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Dick Hardt [mailto:[email-masked]]
> *Sent:* Tuesday, October 31, 2017 9:37 PM
> *To:* Mike Jones <[email-masked]>
> *Cc:* Phil Hunt (IDM) <[email-masked]>; Yaron Sheffer <
> [email-masked]>; Richard Backman, Annabelle <[email-masked]>;
> ID Events Mailing List <[email-masked]>
>
> As you well know, many people in a WG don't look closely at a
> specification until last call is made. Additionally, we are coming up on
> only the 3rd WG meeting. The WG has not existed for very long. While some
> of the participants have been working on this for a while, many have not,
> and we are looking for consensus across the WG.
>
>
>
> As to taking another year, I am hopeful we can resolve the remaining
> issues in SET and publish a new draft for last call. I do not think we will
> need to wait for another WG meeting to ask for last call.
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 1 Nov 2017 06:05:24 +0000

Marius’ proposed syntax, pasted in below, has exactly this characteristic.  The way I see it, his proposal essentially has a primary passwordReset event and a secondary passwordResetExt data structure, which could have been simply another event value in the current draft.

This breaking change makes the data structures more complicated - not less.  And it makes things that used to be possible impossible, reducing flexibility to those who would use the spec.

These seem like bad tradeoffs to me.

{

In particular, it makes it impossible to sign multiple related events sharing a common claims schema with a single signature by the issuer.  It forces the issuer to do the extra work of signing each of the related events (or facets of the same logical event) individually and forces the recipients to do the extra work of checking all those unnecessary signatures.

Not every profile will ever have multiple keys in the “events” set but there’s absolutely no reason to preclude it.

                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Tuesday, October 31, 2017 9:52 PM
To: Mike Jones <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; ID Events Mailing List <[email-masked]>; Phil Hunt (IDM) <[email-masked]>
Subject: Re: [Id-event] Use cases for multiple events per SET?

Please direct me to a proposal that has a "primary" and "secondary" events. I agree that is undesirable. I would also encourage to engage in the discussions so that we can drive clarity and simplicity.

I think having more than one event per SET adds complexity as a receiver must deal with receiving correlated events in one SET as well as correlated events in the same SET.

/Dick

On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I hear you on the fact that different people have joined the effort at different times.  That’s a normal process as an effort builds momentum.  I get that not everyone was there when previous consensus calls were taken.

                                                                -- Mike

From: Dick Hardt [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, October 31, 2017 9:37 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>; ID Events Mailing List <[email-masked]<mailto:[email-masked]>>

Mike

/Dick

                                                       -- Mike

Inline...

Phil

{

{

{

  "iat": 1458496025,

  "aud": [

   ],

   "events": {

       { "resetAttempts":5},

         “sub”:”7375626A656374”,

       }

  }

}

The new proposal:

{

  "iat": 1458496025,

  "aud": [

   ],

   "event": {

     “events”:{

         { "resetAttempts":5},

         “sub”:”7375626A656374”,

       }

     }

   }

}

{

  "iat": 1458496025,

  "aud": [

   ],

   "event": {

      “sub”:”7375626A656374”,

      “events”:{

        {

          “events”:{

               { "resetAttempts":5},

          }

        }

      }

   }

}

{

  "iat": 1458496025,

  "aud": [

   ],

   "event": {

      “sub”:”7375626A656374”,

      “event”:{

        “event”:{

          "resetAttempts":5

        }

      }

   }

}

Phil

Replies inline.

Phil:

/Dick

Thanks,
        Yaron

                                                                 -- Mike

Annabelle,

General extensions

Previous Discussion

Phil

@independentid

    event

    {

       "iat": 1458496404,

       "aud": [

       ],

       "event": {

       }

    }

    **

    *Extensions*

    *Aliases*

    *Related Events*