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

From: Dick Hardt <[email-masked]>
Date: Wed, 1 Nov 2017 09:39:01 -0700

Your comments highlight a couple of points:

1) The example is how to have a predefined extension point for extensions
of a specific event, it is not how to add another event. Myself, I think
this is overly complicated. Events should be comparatively static, and as
with many other JSON formats, the receiver should ignore properties it does
not understand, which let's new properties be introduced as extensions.
There should not be any conflict as extensions should only be done by the
profile that created the event format to start off with.

2) Having an lvalue be a URI is much harder to code against. I'm not sure
why Marius had that in his example. Per the event, the type of the event is
well defined with

"event_type": "https://example.com/scim/event/passwordResetExt",

3) This thread is about reasons for multiple events to be contained in one
set. Your mention of an issuer not wanting to sign separate events as a
reason to allow multiple events. I think we have decided that given a
preference, we will push effort to the transmitter over the receiver as in
many use cases there are many more receivers. Given that, it is more
complex for a receiver to have different ways of managing the receipt of
multiple events as not all issuers will bundle the events, so it is simpler
to have only one event per SET. Including the separate events with a URI as
an lvalue is challenging to implement, speaking from experience.

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

> 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.
>
>
>
> {
>
>   "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,
>
>            }
>
>          }
>
>        }
>
> }
>
>
>
> 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 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]>
>
>
> *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]>
> 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]>
>
>
> *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]> wrote:
>
> Hi Phil
>
>
>
> Correct me if I am misunderstanding, but there is a RISC profile event
>
>
>
> "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”
>
>
>
> 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.
>
> <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.
>
>
>
> {
>
>   "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
>
>        }
>
> }
>
>
>
> {
>
>   "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
>
>   "iat": 1458496025,
>
>   "iss": "https://scim.example.com",
>
>   "aud": [
>
>     "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
>
>     "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
>
>    ],
>
>    "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=>
> ",
>
>    "event": {
>
>        “sub”:”7375626A656374”,
>
>        “iss”:"https://idp.example.com/"
>
>        }
>
> }
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt <[email-masked]> wrote:
>
> 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/\ <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”,
>
>          “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/\ <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”,
>
>          “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/\ <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”,
>
>       “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/\ <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”,
>
>       “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
>
> 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]
>
>
>
> On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle <
> [email-masked]> wrote:
>
>
>
> Replies inline.
>
>
>
> --
>
> Annabelle Richard Backman
>
> 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?
>
>
>
> 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?
>
> [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]
>
>
>
> 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?
>
> [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 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.
> [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:
>
>
>    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.
>
>
>
> 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
>
>
>
> 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]
>
>
>
> 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.
>
>
>
> 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:
>
> 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:
>
> 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,
>
> 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://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=>
>
> 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
> <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]>
>
>     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.
>
>     Here is the example SET from section 2.3, rewritten with this change
>     mind:
>
>     {
>
>        "jti": "4d3559ec67504aaba65d40b0363faad8",
>
>        "iat": 1458496404,
>
>       "iss": "https://scim.example.com <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
>
>     _______________________________________________
>     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=
>
>
>
> _______________________________________________
> Id-event mailing list
> [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]
> 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]
> 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=
>
>
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=U-
> a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=rvdrtI7rYNRAnqZDltCwBAZVHKp-
> MJ20ui2nm46QSz0&e=
>
>
>
>
>
>
>
> --
>
> 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]
> 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=
>
>
>
>
>
> --
>
> Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn
> about projects I am working on!
>
>
>
>
>
> --
>
> Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn
> about projects I am working on!
>

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

---

From: Mike Jones <[email-masked]>
Date: Wed, 1 Nov 2017 18:20:40 +0000

I completely agree on moving complexity to the issuer over the recipient.  In my view, it’s more complex for recipients to have to correlate and process a sequence of multiple SETs providing information about the same logical event, and validate N signatures, than to receive one SET with all the aspects of the logical event as “events” fields, with no correlation over time then required.

                                                       -- Mike

From: Dick Hardt [mailto:[email-masked]]
Sent: Wednesday, November 1, 2017 9:39 AM
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?

1) The example is how to have a predefined extension point for extensions of a specific event, it is not how to add another event. Myself, I think this is overly complicated. Events should be comparatively static, and as with many other JSON formats, the receiver should ignore properties it does not understand, which let's new properties be introduced as extensions. There should not be any conflict as extensions should only be done by the profile that created the event format to start off with.

2) Having an lvalue be a URI is much harder to code against. I'm not sure why Marius had that in his example. Per the event, the type of the event is well defined with

3) This thread is about reasons for multiple events to be contained in one set. Your mention of an issuer not wanting to sign separate events as a reason to allow multiple events. I think we have decided that given a preference, we will push effort to the transmitter over the receiver as in many use cases there are many more receivers. Given that, it is more complex for a receiver to have different ways of managing the receipt of multiple events as not all issuers will bundle the events, so it is simpler to have only one event per SET. Including the separate events with a URI as an lvalue is challenging to implement, speaking from experience.

On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
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.

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

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]<mailto:[email-masked]>] On Behalf Of Dick Hardt
Sent: Tuesday, October 31, 2017 9:52 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>; ID Events Mailing List <[email-masked]<mailto:[email-masked]>>; Phil Hunt (IDM) <[email-masked]<mailto:[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.

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

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!”

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

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”

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

{

{
   "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,

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:

{

  "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”,

       }

     }

   }

}

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

{

  "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},

          }

        }

      }

   }

}

*OR* Following the top layer pattern of singular event  Note that this leads to a triple nested structure.

{

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

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]

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

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

On Oct 29, 2017, at 4:12 PM, Dick Hardt <[email-masked]<mailto:[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.

/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:

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

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

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.

* 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://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=>

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

@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

    {

       "iat": 1458496404,

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

       "aud": [

       ],

       "event": {

         "ref": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",

       }

    }

    **

    *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=

_______________________________________________
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=U-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=rvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm46QSz0&e=

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

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

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

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

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 1 Nov 2017 19:18:15 +0000

Unless the profile guarantees that such related events will always be included in the same SET, then the receiver has to correlate across SETs anyway, and multiple events per SET is just giving the receiver another scenario that they have to support.

I’ve already provided several other reasons why we should not support multiple tokens per SET that no one has addressed. Here they are again:

  1.  Multiple event support 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:
     *   A and B 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.
     *   A is an alias for B, or vice-versa.
     *   A and B are not actually related to one another in any way, and the transmitter bundled them together because they were going to the same receiver.
  3.  Top-level claim semantics become harder to define, as different profiles may want to use the same claims in different ways.
  4.  Event authenticity cannot be verified without having the entire SET. This forces receivers to expose downstream systems to more information necessary, if those systems need to be able to verify authenticity.

From: Mike Jones <[email-masked]>
Date: Wednesday, November 1, 2017 at 11:21 AM
To: Dick Hardt <[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?

                                                       -- Mike

{

                                                       -- Mike

/Dick

                                                                -- Mike

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*

---

From: Phil Hunt <[email-masked]>
Date: Wed, 1 Nov 2017 12:45:08 -0700

You can’t really have multiple events (at least of the same type).  The current spec can only have one instance of a URI (afaik).  

Note that the spec normatively does not support multiple event SETS.  It currently states:
> events
>       The semantics of this claim is to define a set of event statements
>       that each MAY add additional claims to fully describe a single
>       logical event that has occurred (e.g. a state change to a
>       subject).  Multiple event statements of the same type SHALL NOT be
>       accepted.  The "events" claim SHOULD NOT be used to express
>       multiple logical events.

The spec has *always* supported requirements (as stated in the spec) for multiple separate profile statements (from one or more profile familities) needing to be sent as a single message.  It would be INSECURE to force multiple SETs because the current delivery mechanism only allows one SET to be delivered at a time. There is no way to assure that a single receiver gets all of the SETs it needs in a multi-threaded, multi-node environment at scale.  Assembling multiple SETs to track “txn” in a common state database is NOT simple nor cost effective.  

If we accommodate this in the proposed form, we end up with a complex, deeply nested JSON structure with the possibility of namespace conflicts.

IMO The proposal does not simplify, it complicating and limiting.  

The current spec has very clean JSON and avoids namespace conflicts between profiles. I think we should stay on track with the current draft and observe the normative text if not make it stronger in regards to multi-events (understood that Mike may disagree).

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> On Nov 1, 2017, at 12:18 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> Multiple event support 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:
> A and B 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.
> A is an alias for B, or vice-versa.
> A and B are not actually related to one another in any way, and the transmitter bundled them together because they were going to the same receiver.
> Top-level claim semantics become harder to define, as different profiles may want to use the same claims in different ways.
> Event authenticity cannot be verified without having the entire SET. This forces receivers to expose downstream systems to more information necessary, if those systems need to be able to verify authenticity.
>  
> -- 
>   <>
> "event_type": "https://example.com/scim/event/passwordResetExt <https://example.com/scim/event/passwordResetExt>",
>  
> On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>     "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 <https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754>",
>>     "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 <https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7>"
>>    ],
>>    "event_type": "https://example.com/scim/event/passwordResetExt <https://example.com/scim/event/passwordResetExt>",
>>    "event": {  
>>            "https://example.com/scim/event/passwordResetExt <https://example.com/scim/event/passwordResetExt>”: {
>>              "resetAttempts":5,
>>            }
>>          }
>>        }
>> }
>>  
>>   <>
>> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Dick Hardt
>> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
>> Cc: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>>; ID Events Mailing List <[email-masked] <mailto:[email-masked]>>; Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>>
>> 
>> On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>> From: Dick Hardt [mailto:[email-masked] <mailto:[email-masked]>] 
>>> 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]>>
>>> 
>>> On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>>>   <>
>>>> From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]>] 
>>>> 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]>>
>>>> 
>>>> On Oct 30, 2017, at 2:22 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>>> Hi Phil
>>>>>  
>>>>> "https://example.com/scim/event/passwordResetExt <https://example.com/scim/event/passwordResetExt>”
>>>>>  
>>>>>     "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 <https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754>",
>>>>>     "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 <https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7>"
>>>>>    ],
>>>>>    "event_type": "https://example.com/scim/event/passwordResetExt <https://example.com/scim/event/passwordResetExt>",
>>>>>    "event": {  
>>>>>     "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 <https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754>",
>>>>>     "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 <https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7>"
>>>>>    ],
>>>>>    "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=>",
>>>>>    "event": {
>>>>>        “sub”:”7375626A656374”,
>>>>>        “iss”:"https://idp.example.com/ <https://idp.example.com/>"       
>>>>>        }
>>>>> }
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>> On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> Annabelle/Dick,
>>>>>>  
>>>>>>     "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 <https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754>",
>>>>>>     "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 <https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7>"
>>>>>>    ],
>>>>>>    "events": {
>>>>>>      "https://example.com/scim/event/passwordResetExt <https://example.com/scim/event/passwordResetExt>":
>>>>>>        { "resetAttempts":5},
>>>>>>          “iss”:"https://idp.example.com/ <https://idp.example.com/>"
>>>>>>        }
>>>>>>   }
>>>>>> }
>>>>>>  
>>>>>>     "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 <https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754>",
>>>>>>     "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 <https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7>"
>>>>>>    ],
>>>>>>    "event": {
>>>>>>        "https://example.com/scim/event/passwordResetExt <https://example.com/scim/event/passwordResetExt>":
>>>>>>          { "resetAttempts":5},
>>>>>>          “iss”:"https://idp.example.com/ <https://idp.example.com/>"
>>>>>>        }
>>>>>>      }
>>>>>>    }    
>>>>>> }
>>>>>>  
>>>>>>     "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 <https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754>",
>>>>>>     "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 <https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7>"
>>>>>>    ],
>>>>>>    "event": {
>>>>>>       “iss”:"https://idp.example.com/“ <https://idp.example.com/%E2%80%9C>,
>>>>>>       “events”:{
>>>>>>              "https://example.com/scim/event/passwordResetExt <https://example.com/scim/event/passwordResetExt>":
>>>>>>                { "resetAttempts":5},  
>>>>>>           }      
>>>>>>         }
>>>>>>       }     
>>>>>>    }
>>>>>> }
>>>>>>  
>>>>>>     "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 <https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754>",
>>>>>>     "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 <https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7>"
>>>>>>    ],
>>>>>>    "event": {
>>>>>>       “iss”:"https://idp.example.com/“ <https://idp.example.com/%E2%80%9C>,
>>>>>>       “event”:{
>>>>>>           “event_type”:"https://example.com/scim/event/passwordResetExt <https://example.com/scim/event/passwordResetExt>”,
>>>>>>           "resetAttempts":5 
>>>>>>         }
>>>>>>       }     
>>>>>>    }
>>>>>> }
>>>>>>  
>>>>>> 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=>
>>>>>>> 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]>>
>>>>>>> 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:
>>>>>>>>  
>>>>>>>> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>>> *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": [
>>>>>>>>>> 
>>>>>>>>>>          "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>",
>>>>>>>>>> 
>>>>>>>>>>     [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= <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://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=>
>>>>>>>  
>>>>>>> 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=>
>>>>>>  
>>>>> 
>>>>> 
>>>>> 
>>>>>  
>>>>> --
>>>>> 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!
>>>>> 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= <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=>
>>> 
>>> 
>>>  
>>> --
>>> Subscribe to the HARDTWARE <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=V9gyTTX9qujrC2VliwLPy0-KvxS9pYKJ_-kyDapwO8k&e=> mail list to learn about projects I am working on!
>> 
>> 
>> 
>>  
>> --
>> Subscribe to the HARDTWARE <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=V9gyTTX9qujrC2VliwLPy0-KvxS9pYKJ_-kyDapwO8k&e=> mail list to learn about projects I am working on!
> 
> 
> 
>  
> -- 
> Subscribe to the HARDTWARE <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=V9gyTTX9qujrC2VliwLPy0-KvxS9pYKJ_-kyDapwO8k&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=sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=gdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&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=sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=gdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=>

---

From: Mike Jones <[email-masked]>
Date: Wed, 1 Nov 2017 19:57:09 +0000

This well said, Phil.  You did a great job explaining how making the “events” claim single-valued and forcing multiple SETs when one will do significantly complicates life for all parties.

I agree that we probably want to examine the existing descriptive text and make it clear that what’s in the “events” set are multiple aspects of the same logical event – not distinct events.  I’m great with strengthening those statements if they aren’t already clear enough.

                                                                Best wishes,
                                                                -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Wednesday, November 1, 2017 12:45 PM
To: Richard Backman, Annabelle <[email-masked]>
Cc: Mike Jones <[email-masked]>; Dick Hardt <[email-masked]>; Yaron Sheffer <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Use cases for multiple events per SET?

events

      multiple logical events.

Phil

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

On Nov 1, 2017, at 12:18 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

  1.  Top-level claim semantics become harder to define, as different profiles may want to use the same claims in different ways.
  2.  Event authenticity cannot be verified without having the entire SET. This forces receivers to expose downstream systems to more information necessary, if those systems need to be able to verify authenticity.

From: Mike Jones <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 1, 2017 at 11:21 AM
To: Dick Hardt <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, ID Events Mailing List <[email-masked]<mailto:[email-masked]>>, "Phil Hunt (IDM)" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Id-event] Use cases for multiple events per SET?

                                                       -- Mike

{

                                                       -- Mike

/Dick

                                                                -- Mike

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”,

      “iss”:"https://idp.example.com/“<https://idp.example.com/%E2%80%9C>,

      “events”:{

        {

          “events”:{

               { "resetAttempts":5},

          }

        }

      }

   }

}

{

  "iat": 1458496025,

  "aud": [

   ],

   "event": {

      “sub”:”7375626A656374”,

      “iss”:"https://idp.example.com/“<https://idp.example.com/%E2%80%9C>,

      “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<https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=V9gyTTX9qujrC2VliwLPy0-KvxS9pYKJ_-kyDapwO8k&e=> mail list to learn about projects I am working on!

--
Subscribe to the HARDTWARE<https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=V9gyTTX9qujrC2VliwLPy0-KvxS9pYKJ_-kyDapwO8k&e=> mail list to learn about projects I am working on!

--
Subscribe to the HARDTWARE<https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=V9gyTTX9qujrC2VliwLPy0-KvxS9pYKJ_-kyDapwO8k&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=sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=gdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 1 Nov 2017 20:19:42 +0000

Phil,

The normative text you quoted addresses only one example of one of the issues I’ve raised. Even then, I expect this text will be ignored – intentionally or unintentionally – because the structure of a SET as it is defined in the draft allow for this requirement to be violated, and the implied semantics contradict it. No one will look at a SET, see a plural “events” member, and understand that it means “multiple event statements” and not “multiple events.”

> There is no way to assure that a single receiver gets all of the SETs it needs in a multi-threaded, multi-node environment at scale.

This is what the acknowledgement mechanisms in the delivery spec are for. Transmitters can correlate acknowledgements of different SETs, at scale if necessary. In all the SET use cases we’ve discussed, the volume of SETs on a stream only scales with the receiver’s business, so only receivers who are already operating at scale need to be capable of handling SETs at scale. If you disagree, please provide a counterexample.

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

events

      multiple logical events.

Phil

                                                       -- Mike

{

                                                       -- Mike

/Dick

                                                                -- Mike

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*

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 1 Nov 2017 14:37:46 -0700

On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt <[email-masked]> wrote:

> You can’t really have multiple events (at least of the same type).  The
> current spec can only have one instance of a URI (afaik).
>
>       *The semantics of this claim is to define a set of event statements
>       logical event* that has occurred (e.g. a state change to a
> The spec has *always* supported requirements (as stated in the spec) for
> multiple separate profile statements (from one or more profile familities)
> needing to be sent as a single message.  It would be INSECURE to force
> multiple SETs because the current delivery mechanism only allows one SET to
> be delivered at a time. There is no way to assure that a single receiver
> gets all of the SETs it needs in a multi-threaded, multi-node environment
> at scale.  Assembling multiple SETs to track “txn” in a common state
> database is NOT simple nor cost effective.
>

I totally agree that it is difficult for receivers to receive separate
events, in no particular order and correlate based on "txn". But, receivers
have to solve this issue regardless of "events" or "event", so it is
unrelated to this proposal.

>
> If we accommodate this in the proposed form, we end up with a complex,
> deeply nested JSON structure with the possibility of namespace conflicts.
>
> The current spec has very clean JSON and avoids namespace conflicts
> between profiles. I think we should stay on track with the current draft
> and observe the normative text if not make it stronger in regards to
> multi-events (understood that Mike may disagree).
>
> Phil
>
> Unless the profile guarantees that such related events will always be
> included in the same SET, then the receiver has to correlate across SETs
> anyway, and multiple events per SET is just giving the receiver another
> scenario that they have to support.
>
> I’ve already provided several other reasons why we should not support
> multiple tokens per SET that no one has addressed. Here they are again:
>
>    1. Multiple event support results in a more complex structure for the
>    single event use case, which I think we all agree is the majority use case.
>       1. A and B are related to the same logical event (i.e. the same
>       thing as if they were from different SETs that have a common txn).
>       4. A is an alias for B, or vice-versa.
>       5. A and B are not actually related to one another in any way, and
>       the transmitter bundled them together because they were going to the same
>       receiver.
>    3. Top-level claim semantics become harder to define, as different
>    profiles may want to use the same claims in different ways.
>    4. Event authenticity cannot be verified without having the entire
>    SET. This forces receivers to expose downstream systems to more information
>    necessary, if those systems need to be able to verify authenticity.
>
>
> --
> *From: *Mike Jones <[email-masked]>
> *Date: *Wednesday, November 1, 2017 at 11:21 AM
> *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?
>
> I completely agree on moving complexity to the issuer over the recipient.
> In my view, it’s more complex for recipients to have to correlate and
> process a sequence of multiple SETs providing information about the same
> logical event, and validate N signatures, than to receive one SET with all
> the aspects of the logical event as “events” fields, with no correlation
> over time then required.
>
>                                                        -- Mike
>
> *From:* Dick Hardt [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, November 1, 2017 9:39 AM
> *From:* Id-event [mailto:[email-masked]] *On Behalf Of *Dick
> Hardt
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=V9gyTTX9qujrC2VliwLPy0-KvxS9pYKJ_-kyDapwO8k&e=>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=V9gyTTX9qujrC2VliwLPy0-KvxS9pYKJ_-kyDapwO8k&e=>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=V9gyTTX9qujrC2VliwLPy0-KvxS9pYKJ_-kyDapwO8k&e=>
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=
> sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=
> gdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=
>
>
>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 1 Nov 2017 14:45:02 -0700

Per my earlier message, a receiver will often be receiving events from
multiple transmitters for the same subject. The receiver will already need
a mechanism to correlate events on the same subject, A transmitter may have
different services issuing SETs that are tied to the same event, and have
the same transaction, but are transmitted separately.

Will this not be the case? Given this, a receiver MUST be doing correlation
across SETs.

On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu <[email-masked]>
wrote:

>> *Cc: *Yaron Sheffer <[email-masked]>, "Richard Backman,
>> Annabelle" <[email-masked]>, ID Events Mailing List <
>> [email-masked]>, "Phil Hunt (IDM)" <[email-masked]>
>> I completely agree on moving complexity to the issuer over the
>> recipient.  In my view, it’s more complex for recipients to have to
>> correlate and process a sequence of multiple SETs providing information
>> about the same logical event, and validate N signatures, than to receive
>> one SET with all the aspects of the logical event as “events” fields, with
>> no correlation over time then required.
>>
>>                                                        -- Mike
>>
>> 3) This thread is about reasons for multiple events to be contained in
>> one set. Your mention of an issuer not wanting to sign separate events as a
>> Since this is a framework, it is expected that as different groups
>> profile it, there will be additional feedback.
>>
>> 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
>> [email-masked]>; Mike Jones <[email-masked]>; ID
>> Events Mailing List <[email-masked]>
>>
>>    "event_type": "http://schemas.openid.net/sec
>> event/risc/event-type/account-credential-change-required
>> 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=
>>
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1i
>> w&s=WrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=U-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGie
>> c&s=rvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm46QSz0&e=
>>
>>
>>
>>
>>
>>
>> --
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_
>> w&s=Oe0qfLEX83vtXM7Wl2cYBe-Gg1DVPjhXjVJkfhVRzwc&e=
>>
>>
>>
>>
>> --
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhl
>> o&s=gdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=
>>
>>
>>

---

From: William Denniss <[email-masked]>
Date: Wed, 1 Nov 2017 14:46:53 -0700

Perhaps I can try and explain the original intent of the current design.
The goal was always that a SET represents a single logical event. However
multiple systems may have different representations of the event – the
example given originally was one formatted for RISC, and one for SCIM.

A good analogy is email. You send a single logical email, which may have
two representations, HTML and plain text. Systems can consume the version
that they understand and ignore the one they don't.

I'm starting to regret the plural in "events", it was pluralized due to it
being an array, not because it represented multiple logical events.

Annabelle, I understand your concerns regarding confusion of the semantics
between the JSON syntax and the specification language. Are there other
ways to resolve that without removing the ability for multiple
representations of the same event?

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 1 Nov 2017 14:54:45 -0700

> that they understand and ignore the one they don't.

Yes, and I think this is well understood.

> being an array, not because it represented multiple logical events.

I don't think this is the main concern or cause for confusion.

> representations of the same event?

The argument is that multiple representations can be sent as distinct SETs,
if really needed. In practice this will happen quite rare though. Events
are created for a specific receiver, the receiver either wants the SCIM or
the RISC flavor, and they should be able to specify that in configuration
(there is a proposal how to capture that).

Do we have a compelling use case where a receiver must receive multiple
variants all at once?

>>>    1. Multiple event support results in a more complex structure for
>>>    the single event use case, which I think we all agree is the majority use
>>>    case.
>>>       5. A and B are not actually related to one another in any way,
>>>       and the transmitter bundled them together because they were going to the
>>>       same receiver.
>>> *Cc:* Yaron Sheffer <[email-masked]>; Richard Backman, Annabelle
>>> <[email-masked]>; ID Events Mailing List <[email-masked]>; Phil
>>> 1) The example is how to have a predefined extension point for
>>> extensions of a specific event, it is not how to add another event. Myself,
>>> I think this is overly complicated. Events should be comparatively static,
>>> and as with many other JSON formats, the receiver should ignore properties
>>> it does not understand, which let's new properties be introduced as
>>> extensions. There should not be any conflict as extensions should only be
>>> done by the profile that created the event format to start off with.
>>>
>>> 2) Having an lvalue be a URI is much harder to code against. I'm not
>>> sure why Marius had that in his example. Per the event, the type of the
>>> event is well defined with
>>>
>>> On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones <
>>> [email-masked]> wrote:
>>>
>>> *Cc:* Yaron Sheffer <[email-masked]>; Richard Backman, Annabelle
>>> <[email-masked]>; ID Events Mailing List <[email-masked]>; Phil
>>> 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
>>> 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
>>> On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones <
>>> [email-masked]> wrote:
>>>
>>> *Cc:* Yaron Sheffer <[email-masked]>; Richard Backman, Annabelle
>>> <[email-masked]>; Mike Jones <[email-masked]>; ID
>>> 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]
>>>    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).
>>>    1. Claim semantics become harder to define, as different profiles
>>>    may want to use the same claims in different ways.
>>>
>>>
>>> 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
>>> 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
>>>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.i
>>> etf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaW
>>> HvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEiv
>>> zjWwlNKe4C_lLIGk&m=s5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSib
>>> Ec&s=X8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=
>>>
>>>
>>>
>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqP
>>> kAI1aLcLN4KZNA&m=YBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw
>>> &s=WrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=
>>>
>>>
>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqP
>>> kAI1aLcLN4KZNA&m=U-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec
>>> &s=rvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm46QSz0&e=
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqP
>>> kAI1aLcLN4KZNA&m=iyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w
>>> &s=Oe0qfLEX83vtXM7Wl2cYBe-Gg1DVPjhXjVJkfhVRzwc&e=
>>>
>>>
>>>
>>>
>>> --
>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqP
>>> kAI1aLcLN4KZNA&m=sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo
>>> &s=gdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=
>>>
>>>
>>>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 1 Nov 2017 14:59:38 -0700

I think that is a red herring. 

The issue is a multipayload message may be needed (for many reasons already discussed) to convey one logical event. 

An event from more than one txn are separate and distinct. 

There may be cumulative conclusions but that is not in scope.  

Breaking a single logical event across multiple sets is a different thing. It requires multi part signaling for the receiver to know they have the complete message. More complexity in both delivery and set. 

None of this is needed. 

Phil

> On Nov 1, 2017, at 2:45 PM, Dick Hardt <[email-masked]> wrote:
> 
> Per my earlier message, a receiver will often be receiving events from multiple transmitters for the same subject. The receiver will already need a mechanism to correlate events on the same subject, A transmitter may have different services issuing SETs that are tied to the same event, and have the same transaction, but are transmitted separately.
> 
> Will this not be the case? Given this, a receiver MUST be doing correlation across SETs. 
> 
>> On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu <[email-masked]> wrote:
>> I totally agree that it is difficult for receivers to receive separate events, in no particular order and correlate based on "txn". But, receivers have to solve this issue regardless of "events" or "event", so it is unrelated to this proposal.
>> 
>>  
>>> 
>>>>> On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones <[email-masked]> wrote:
>>>>> From: Id-event [mailto:[email-masked]] On Behalf Of Dick Hardt
>>>>>> On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones <[email-masked]> wrote:
>>>>>> Cc: Phil Hunt (IDM) <[email-masked]>; Yaron Sheffer <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; ID Events Mailing List <[email-masked]>
>>>>>> 
>>>>>>> On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones <[email-masked]> wrote:
>>>>>>> From: Phil Hunt (IDM) [mailto:[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/account-credential-change-required”
>>>>>>>>  
>>>>>>>>    "event_type": "http://schemas.openid.net/secevent/risc/event-type/account-credential-change-required",
>>>>>>>>    "event": {
>>>>>>>>        “sub”:”7375626A656374”,
>>>>>>>>>      "http://schemas.openid.net/secevent/risc/event-type/\
>>>>>>>>>        "http://schemas.openid.net/secevent/risc/event-type/\
>>>>>>>>>      “event_type”:"http://schemas.openid.net/secevent/risc/event-type/\
>>>>>>>>>      “event_type”:"http://schemas.openid.net/secevent/risc/event-type/\
>>>>>>>>>> On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle <[email-masked]> wrote:
>>>>>>>>>>  
>>>>>>>>>> Replies inline.
>>>>>>>>>>  
>>>>>>>>>> -- 
>>>>>>>>>> Cc: Yaron Sheffer <[email-masked]>, Mike Jones <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, ID Events Mailing List <[email-masked]>
>>>>>>>>>>>> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer <[email-masked]> wrote:
>>>>>>>>>>>>> *From:* Id-event [mailto:[email-masked]] *On Behalf Of *Phil Hunt
>>>>>>>>>>>>> www.independentid.com <http://www.independentid.com>
>>>>>>>>>>>>> 
>>>>>>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am working on!
>>>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am working on!
>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am working on!
>>>>> 
>>>>> 
>>>>> 
>>>>>  
>>>>> --
>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am working on!
>>>> 
>>>> 
>>>> 
>>>>  
>>>> -- 
>>>> Subscribe to the HARDTWARE mail list to learn about projects I am working on!
> Subscribe to the HARDTWARE mail list to learn about projects I am working on!

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 1 Nov 2017 15:00:44 -0700

+1

Phil

> On Nov 1, 2017, at 2:46 PM, William Denniss <[email-masked]> wrote:
> 
> Perhaps I can try and explain the original intent of the current design. The goal was always that a SET represents a single logical event. However multiple systems may have different representations of the event – the example given originally was one formatted for RISC, and one for SCIM.
> 
> A good analogy is email. You send a single logical email, which may have two representations, HTML and plain text. Systems can consume the version that they understand and ignore the one they don't.
> 
> I'm starting to regret the plural in "events", it was pluralized due to it being an array, not because it represented multiple logical events.
> 
> Annabelle, I understand your concerns regarding confusion of the semantics between the JSON syntax and the specification language. Are there other ways to resolve that without removing the ability for multiple representations of the same event?
>

---

From: William Denniss <[email-masked]>
Date: Wed, 1 Nov 2017 15:00:59 -0700

The receiver probably knows which version they want, but does the sender?
Using the email analogy, you may have configured your email client to
accept plain text only. Fortunately, my client sends both – not knowing
what you prefer – and you are able to view my message.

I think it would help if we broke this problem down into two parts. 1/ Are
multi-format SETs desirable? That's been the design since the earliest
version. 2/ What is the best representation of the SET based on what we
decide for #1.

My understanding was that the "events" plural (related to #2, the best
representation of a SET) *was* in fact a concern, as people may skip the
text and look directly at the JSON syntax, then jump to conclusions.

On Wed, Nov 1, 2017 at 2:54 PM, Marius Scurtescu <[email-masked]>
wrote:

>> I'm starting to regret the plural in "events", it was pluralized due to
>> it being an array, not because it represented multiple logical events.
>>
>
>> Annabelle, I understand your concerns regarding confusion of the
>> semantics between the JSON syntax and the specification language. Are there
>> other ways to resolve that without removing the ability for multiple
> The argument is that multiple representations can be sent as distinct
> SETs, if really needed. In practice this will happen quite rare though.
> Events are created for a specific receiver, the receiver either wants the
> SCIM or the RISC flavor, and they should be able to specify that in
> configuration (there is a proposal how to capture that).
>
>>>> The spec has *always* supported requirements (as stated in the spec)
>>>> for multiple separate profile statements (from one or more profile
>>>> familities) needing to be sent as a single message.  It would be INSECURE
>>>> to force multiple SETs because the current delivery mechanism only allows
>>>> one SET to be delivered at a time. There is no way to assure that a single
>>>> receiver gets all of the SETs it needs in a multi-threaded, multi-node
>>>> environment at scale.  Assembling multiple SETs to track “txn” in a common
>>>> state database is NOT simple nor cost effective.
>>>>
>>>
>>>>    2. Multiple-event SETs have ambiguous semantics. The presence of
>>>>    two events A and B in the same SET could mean any of:
>>>> *Cc:* Yaron Sheffer <[email-masked]>; Richard Backman,
>>>> Annabelle <[email-masked]>; ID Events Mailing List <
>>>> [email-masked]>; Phil Hunt (IDM) <[email-masked]>
>>>> *Cc:* Yaron Sheffer <[email-masked]>; Richard Backman,
>>>> Annabelle <[email-masked]>; ID Events Mailing List <
>>>> [email-masked]>; Phil Hunt (IDM) <[email-masked]>
>>>>
>>>> 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
>>>>
>>>> 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
>>>> *Cc:* Yaron Sheffer <[email-masked]>; Richard Backman,
>>>> Annabelle <[email-masked]>; Mike Jones <
>>>> [email-masked]>; ID Events Mailing List <[email-masked]
>>>> >
>>>>
>>>> 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.
>>>>
>>>>
>>>> [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]
>>>>
>>>>    2. Multiple-event SETs have ambiguous semantics. The presence of
>>>>    two events A and B in the same SET could mean any of:
>>>>
>>>>
>>>> [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
>>>>
>>>> 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
>>>> Profiling specifications SHOULD define the allowed event statements,
>>>> and MAY restrict their number. For example, some profiles may require this
>>>> 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
>>>> I note that I originally raised having an attribute to designate
>>>> primary event attribute to alleviate your concern, but this was not
>>>> accepted. See:
>>>>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 1 Nov 2017 15:06:25 -0700

I don't see multi variants. I see multiple parts

For example you have all the risc events

Not to support implicit federation users (which have to be identified by one or more identifiers), you might define a utility event profile which contains attributes for email, telephone, username etc.

If you didn't get both parts of the set as one set it would have different meaning or be considered malformed. 

The advantage in risc is not having to have a tonne of optional id attributes in every event. 

The point here is reasonable flexibility for profilers to decide. 

Finally i already gave the overlapped risc/scim password reset case. 

Phil

> On Nov 1, 2017, at 2:54 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> The argument is that multiple representations can be sent as distinct SETs, if really needed. In practice this will happen quite rare though. Events are created for a specific receiver, the receiver either wants the SCIM or the RISC flavor, and they should be able to specify that in configuration (there is a proposal how to capture that).
> 
> Do we have a compelling use case where a receiver must receive multiple variants all at once?
> 
>  
>> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=uNiWQlyKGTu-9p5qJLRS1F-3yKXpDAB7KtpkCDc_JCU&s=F8_j8RZDlbUP1p-1QfgOEnrZO-3Iag7Yul1NK1xp4Js&e=

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 1 Nov 2017 15:08:33 -0700

> what you prefer – and you are able to view my message.

Two solutions:
- since receiver knows what version they want they are going to only
consume that and ignore the other
- there is a proposal underway so that receivers can tell the sender
exactly what they want, no events dropped on the floor

> version. 2/ What is the best representation of the SET based on what we

Yes, and #1 above is being challenged.

>>>>> You can’t really have multiple events (at least of the same type).
>>>>> The current spec can only have one instance of a URI (afaik).
>>>>>
>>>>> 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
>>>>>
>>>>> [email-masked]>; Richard Backman, Annabelle <
>>>>> [email-masked]>; ID Events Mailing List <[email-masked]>
>>>>>
>>>>> 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.
>>>>>
>>>>> 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!
>>>>>
>>>>> [email-masked]>; ID Events Mailing List <
>>>>> [email-masked]>
>>>>>
>>>>> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer <[email-masked]
>>>>> > wrote:
>>>>>
>>>>> * 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.
>>>>>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 1 Nov 2017 15:11:59 -0700

The two control plane proposals don't actually support composite events. They only indicate a primary event. The txr is free to attach composite extensions as it thinks needed. 

We may still have to address that. 

Phil

> On Nov 1, 2017, at 3:08 PM, Marius Scurtescu <[email-masked]> wrote:
> 
>> The receiver probably knows which version they want, but does the sender? Using the email analogy, you may have configured your email client to accept plain text only. Fortunately, my client sends both – not knowing what you prefer – and you are able to view my message.
> 
> Two solutions:
> - since receiver knows what version they want they are going to only consume that and ignore the other
> - there is a proposal underway so that receivers can tell the sender exactly what they want, no events dropped on the floor
> 
> 
>> 
>> I think it would help if we broke this problem down into two parts. 1/ Are multi-format SETs desirable? That's been the design since the earliest version. 2/ What is the best representation of the SET based on what we decide for #1.
> 
>> My understanding was that the "events" plural (related to #2, the best representation of a SET) was in fact a concern, as people may skip the text and look directly at the JSON syntax, then jump to conclusions.
>> 
>>> On Wed, Nov 1, 2017 at 2:54 PM, Marius Scurtescu <[email-masked]> wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=WgSxaGY2szLNY2pvZLIU-OmBFEkwrzR3P4pC1N0D-t8&s=DyaPmvYSTL3a3Yicb4AoEgJGAaNNxz8jsrgcbZaOsdc&e=

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 1 Nov 2017 22:52:41 +0000

This analogy is fundamentally flawed. With email, both the text and HTML bodies are different representations of the exact same message, with the exact same semantics. A reader is generally assumed to interpret and react to a message the same way, whether they read it in text or HTML. This is not the case for the events within SETs. The OIDC Backchannel Logout event, a SCIM Logout event, and a hypothetical RISC Logout event all convey different information and are sent under different circumstances, and it is expected that receivers may react differently to each event. They may even be received by different endpoints – some going to the receiver’s session management system while others go to their risk management system (which could even be a third party). Since each event type contains different information, it may even be important from a data exposure standpoint to the receiver that these events not all pass through the same systems on their side, or for the receiver to only receive one of those types of events, and not the other. This is the case for Amazon; we want RISC events, and no others; we don’t want to receive any more information from transmitters than is necessary.

From: Id-event <[email-masked]> on behalf of William Denniss <[email-masked]>
Date: Wednesday, November 1, 2017 at 3:02 PM
To: Marius Scurtescu <[email-masked]>
Cc: "Richard Backman, Annabelle" <[email-masked]>, Yaron Sheffer <[email-masked]>, Mike Jones <[email-masked]>, Phil Hunt <[email-masked]>, ID Events Mailing List <[email-masked]>, Dick Hardt <[email-masked]>
Subject: Re: [Id-event] Use cases for multiple events per SET?

On Wed, Nov 1, 2017 at 2:54 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Nov 1, 2017 at 2:46 PM, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:
Perhaps I can try and explain the original intent of the current design. The goal was always that a SET represents a single logical event. However multiple systems may have different representations of the event – the example given originally was one formatted for RISC, and one for SCIM.

On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
You can’t really have multiple events (at least of the same type).  The current spec can only have one instance of a URI (afaik).

events

      multiple logical events.

Phil

                                                       -- Mike

{

                                                       -- Mike

/Dick

                                                                -- Mike

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*

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 1 Nov 2017 22:54:49 +0000

Phil, I don’t follow what you’re describing in this scenario. Can you provide an example?

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wednesday, November 1, 2017 at 3:07 PM
To: Marius Scurtescu <[email-masked]>
Cc: William Denniss <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, Yaron Sheffer <[email-masked]>, Mike Jones <[email-masked]>, ID Events Mailing List <[email-masked]>, Dick Hardt <[email-masked]>
Subject: Re: [Id-event] Use cases for multiple events per SET?

Phil

On Nov 1, 2017, at 2:54 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Nov 1, 2017 at 2:46 PM, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:
Perhaps I can try and explain the original intent of the current design. The goal was always that a SET represents a single logical event. However multiple systems may have different representations of the event – the example given originally was one formatted for RISC, and one for SCIM.

events

      multiple logical events.

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=uNiWQlyKGTu-9p5qJLRS1F-3yKXpDAB7KtpkCDc_JCU&s=lrcWtLo6ZA_2poYZwmymiiicNlwykyQJok3GeccGAYY&e=>
[email-masked]<mailto:[email-masked]>

                                                       -- Mike

{

                                                       -- Mike

/Dick

                                                                -- Mike

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*

_______________________________________________
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=uNiWQlyKGTu-9p5qJLRS1F-3yKXpDAB7KtpkCDc_JCU&s=F8_j8RZDlbUP1p-1QfgOEnrZO-3Iag7Yul1NK1xp4Js&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=uNiWQlyKGTu-9p5qJLRS1F-3yKXpDAB7KtpkCDc_JCU&s=F8_j8RZDlbUP1p-1QfgOEnrZO-3Iag7Yul1NK1xp4Js&e=>