Subject: [Id-event] Dealing with issuer conflict

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 17 May 2017 21:40:42 -0700

In many cases where we are talking about events (eg risc) there is no need for extra claims other than the event type itself. 

It occurs to me that in the case of RP issued events the current sectoken format requires an embedded iss to deal with the conflict with the set issuer. It seems to add a lot of complication for most events. 

What if we defined a new sectoken top level attribute 'subIss' to mean "subject issuer" and keep iss reserved for the SET issuer. 

I would suggest this as a recommended attribute even when iss and subIss are the same for parsing consistency. 

Thoughts?

Phil

---

From: Dick Hardt <[email-masked]>
Date: Thu, 18 May 2017 13:36:56 +0000

Phil, would you clarify the use case and the requirement to ensure everyone
on the list is aligned? Thanks

On Wed, May 17, 2017 at 9:45 PM Phil Hunt (IDM) <[email-masked]>
wrote:

> In many cases where we are talking about events (eg risc) there is no need
> for extra claims other than the event type itself.
>
> It occurs to me that in the case of RP issued events the current sectoken
> format requires an embedded iss to deal with the conflict with the set
> issuer. It seems to add a lot of complication for most events.
>
> What if we defined a new sectoken top level attribute 'subIss' to mean
> "subject issuer" and keep iss reserved for the SET issuer.
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
-- 
Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about
projects I am working on!

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 18 May 2017 07:30:37 -0700

??

Happens in any case where sub is not globally identifiable. 

In Connect, since sub is not uniquely identified, the iss for the sub must be included. This creates a conflict if the issuer of the SET is not the issuer of the subject. 

Resolving the iss conflict has been on the list of issues since chicago. 

In RISC we were discussing account close events. I am assume one of the scenarios is RPs will notify IDPs when they close an account. They must use an iss not associated with sub. As things stand now, they will have to assert the extra iss value in their payload---which for most events is complex to parse since their are no other extra claims. 

Phil

> On May 18, 2017, at 6:36 AM, Dick Hardt <[email-masked]> wrote:
> 
> Phil, would you clarify the use case and the requirement to ensure everyone on the list is aligned? Thanks
> 
>> On Wed, May 17, 2017 at 9:45 PM Phil Hunt (IDM) <[email-masked]> wrote:
> Subscribe to the HARDTWARE mail list to learn about projects I am working on!
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=p1Vsd1Hb7BX87sV4x9MhtsGbORcuiacHxujwThSnWh4&s=ATYzOXXGto5afit3OgTjh19KczxKCvaBwC7ftofHMrs&e=

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 May 2017 17:40:39 +0000

I believe that the solution already discussed is the best one.  If the event issuer is different than a logical issuer associated with the event subject, then put the logical “iss” and “sub” values inside the event.  Any “sub” at the top-level (if any) should be associated with the “iss” at the top-level, which is always the event issuer.

Any proposal that requires duplicating information, such as requiring “subIss” even when it’s always identical to “iss”, is not a great architectural choice, since it creates unnecessary error conditions that would not otherwise be possible.  (How should implementations handle the case where two values are required to match but don’t?)

                                                                -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt (IDM)
Sent: Thursday, May 18, 2017 7:31 AM
To: Dick Hardt <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Dealing with issuer conflict

??

Phil

On May 18, 2017, at 6:36 AM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
Phil, would you clarify the use case and the requirement to ensure everyone on the list is aligned? Thanks

On Wed, May 17, 2017 at 9:45 PM Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:
In many cases where we are talking about events (eg risc) there is no need for extra claims other than the event type itself.

Thoughts?

Phil
_______________________________________________
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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=p1Vsd1Hb7BX87sV4x9MhtsGbORcuiacHxujwThSnWh4&s=ATYzOXXGto5afit3OgTjh19KczxKCvaBwC7ftofHMrs&e=>
--
Subscribe to the HARDTWARE<https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=p1Vsd1Hb7BX87sV4x9MhtsGbORcuiacHxujwThSnWh4&s=NGbCAfBEl5TtskWdjjWOY2cQJA3Fsy9QvntPnstyIkc&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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=p1Vsd1Hb7BX87sV4x9MhtsGbORcuiacHxujwThSnWh4&s=ATYzOXXGto5afit3OgTjh19KczxKCvaBwC7ftofHMrs&e=

---

From: Phil Hunt <[email-masked]>
Date: Thu, 18 May 2017 11:41:15 -0700

Mike,

I’m not sure we’re on the same page here. My impression is this is still on the outstanding list.

Let’s look at some example cases:

For example, if a relying party (e.g. retail store) wants to notify an IDP that the user has been deleted…

Currently in the draft:
When issued by an OpenID Connect issuer:
{
  "iss": "https://connect.myidp.com",
  "sub": "248289761001",
  "aud": ["connect.myidp.com"],
  "iat": 1471566154,
  "jti": "bWJq",
  "events": {
    "http://schemas.openid.net/risc/event-type/account-deleted": {}
  }
}

BUT, when issued by a party other than the issuer of the subject:
{
  "iss": "https://exampleretail.store.com",
  "sub": "248289761001",
  "aud": ["connect.myidp.com"],
  "iat": 1471566154,
  "jti": "bWJq",
  "events": {
    "http://schemas.openid.net/risc/event-type/account-deleted": {
      "iss”:"connect.myidp.com”
    }
  }
}

If you are writing code, if you agree that the OP issues a lot of events, you end up having to check that there’s no embedded “iss” present before you can assume the issuer of the subject is the same as that of the SET token.  This strikes me as very complex.

Regarding your assertion:
> Any “sub” at the top-level (if any) should be associated with the “iss” at the top-level, which is always the event issuer.

May be you are thinking that we should be solving this by always issuing embedded iss and sub (Alternative 1):
{
  "iss": "https://exampleretail.store.com",  
  "aud": ["connect.myidp.com"],
  "iat": 1471566154,
  "jti": "bWJq",
  "events": {
    "http://schemas.openid.net/risc/event-type/account-deleted": {
      "iss”:”connect.myidp.com”
      "sub": "248289761001",
    }
  }
}

OR, Alternative 2:
{
  "iss": "https://exampleretail.store.com",
  "sub": "248289761001",
  "aud": ["connect.myidp.com"],
  "iat": 1471566154,
  "jti": “bWJq"
  “subIss”:”connect.myidp.com”,
  "events": {
    "http://schemas.openid.net/risc/event-type/account-deleted": {}
  }
}

I can see pros and cons for either. I like option 1 because it also makes the SET different from ID Tokens and Access Tokens.

Option 2 is nice because most SETs we’ve been talking about just have an event type and a subject and no claims.

The best way to define this is to enforce that sub may only be used at the top level if it is globally identifiable (e.g. such as in the case of SCIM URIs).

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> On May 18, 2017, at 10:40 AM, Mike Jones <[email-masked]> wrote:
> 
> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Phil Hunt (IDM)
> To: Dick Hardt <[email-masked] <mailto:[email-masked]>>
> Cc: ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
> On May 18, 2017, at 6:36 AM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Wed, May 17, 2017 at 9:45 PM Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
> [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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=p1Vsd1Hb7BX87sV4x9MhtsGbORcuiacHxujwThSnWh4&s=ATYzOXXGto5afit3OgTjh19KczxKCvaBwC7ftofHMrs&e=>
> -- 
> Subscribe to the HARDTWARE <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=p1Vsd1Hb7BX87sV4x9MhtsGbORcuiacHxujwThSnWh4&s=NGbCAfBEl5TtskWdjjWOY2cQJA3Fsy9QvntPnstyIkc&e=> mail list to learn about projects I am working on!
> [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=p1Vsd1Hb7BX87sV4x9MhtsGbORcuiacHxujwThSnWh4&s=ATYzOXXGto5afit3OgTjh19KczxKCvaBwC7ftofHMrs&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=p1Vsd1Hb7BX87sV4x9MhtsGbORcuiacHxujwThSnWh4&s=ATYzOXXGto5afit3OgTjh19KczxKCvaBwC7ftofHMrs&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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=8LfCYox0y3ghN8YAXLrAb5zfUt5rVD8vbwKwvw8-Rjk&s=gv4-yN8LDVir82WEWzix61-YzkrfquEPKMk_TtLylrw&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=8LfCYox0y3ghN8YAXLrAb5zfUt5rVD8vbwKwvw8-Rjk&s=gv4-yN8LDVir82WEWzix61-YzkrfquEPKMk_TtLylrw&e=>

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 May 2017 19:08:14 +0000

Most of what you’re talking about seems to me to be decisions that can be made by particular event definitions or event family definitions.  I have no problem with particular events or event families employing some of the strategies that you’re describing.  The SET spec already facilitates that.

But per previous discussions, we shouldn’t be making restrictions in the SET spec that limit its applicability by making restrictions on claims usage that will only work for some event use cases and will rule out others.  We should hold to the bright-line test that event definitions define what claims are included in SETS (other than the “events” claim itself) and how they’re used.  Intruding on that will unnecessarily limit the applicability of SETs.

                                                                -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Thursday, May 18, 2017 11:41 AM
To: Mike Jones <[email-masked]>
Cc: Dick Hardt <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Dealing with issuer conflict

Mike,

Currently in the draft:

  "sub": "248289761001",

  "aud": ["connect.myidp.com<http://connect.myidp.com>"],

  "iat": 1471566154,

  "jti": "bWJq",

  "events": {

  }

}

{

  "sub": "248289761001",

  "aud": ["connect.myidp.com<http://connect.myidp.com>"],

  "iat": 1471566154,

  "jti": "bWJq",

  "events": {

      "iss”:"connect.myidp.com<http://connect.myidp.com>”

    }

  }

}

{

  "aud": ["connect.myidp.com<http://connect.myidp.com>"],

  "iat": 1471566154,

  "jti": "bWJq",

  "events": {

      "iss”:”connect.myidp.com<http://connect.myidp.com>”

      "sub": "248289761001",

    }

  }

}

OR, Alternative 2:

{

  "sub": "248289761001",

  "aud": ["connect.myidp.com<http://connect.myidp.com>"],

  "iat": 1471566154,

  "jti": “bWJq"

  “subIss”:”connect.myidp.com<http://connect.myidp.com>”,

  "events": {

  }

}

Phil

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

On May 18, 2017, at 10:40 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                                -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt (IDM)
Sent: Thursday, May 18, 2017 7:31 AM
To: Dick Hardt <[email-masked]<mailto:[email-masked]>>
Cc: ID Events Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Dealing with issuer conflict

??

Phil

Thoughts?

Phil
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=8LfCYox0y3ghN8YAXLrAb5zfUt5rVD8vbwKwvw8-Rjk&s=gv4-yN8LDVir82WEWzix61-YzkrfquEPKMk_TtLylrw&e=

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 18 May 2017 12:34:21 -0700

Thanks Mike. 

I think we disagree.

The concern I have is that most implementers will have to write code that always checks for the absence of a duplicate issuer claim because it changes the meaning of subject.

This strikes me as complexity that needs to be dealt with in the core spec. It stems from our SecToken's use of JWT and its popular use today.

If every profiling spec can do this differently requiring different parsers whats the point of secevents?

Phil

> On May 18, 2017, at 12:08 PM, Mike Jones <[email-masked]> wrote:
> 
> www.independentid.com
> [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 May 2017 19:46:40 +0000

In many use cases, only SETs from a single event family will be legal and all will use the same claims conventions.  In that case, a normal JWT parser will likely be used and the application will process the additional event-specific claims.  There’s no general-purpose SET parser in the mix.

I think that trying to architect this for a world in which there’s a single SET parser for SETs of all kinds would skew the architecture and have the unintended side-effect of excluding some use cases through unnecessary complexity.

The SET spec should define the “events” claim and stop there.  SET is already poised for success as it is now.  We shouldn’t add restrictions that will jeopardize that achievement.  Events and event families should do the rest, in ways appropriate to their use cases.

                                                                -- Mike

P.S.  How to represent RISC events that might be issued either by an Identity Provider or Relying party is an entirely appropriate discussion to have in the RISC working group, but not here in the ID Events working group.

From: Phil Hunt (IDM) [mailto:[email-masked]]
Sent: Thursday, May 18, 2017 12:34 PM
To: Mike Jones <[email-masked]>
Cc: Dick Hardt <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Dealing with issuer conflict

Thanks Mike.

I think we disagree.

Phil

On May 18, 2017, at 12:08 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Most of what you’re talking about seems to me to be decisions that can be made by particular event definitions or event family definitions.  I have no problem with particular events or event families employing some of the strategies that you’re describing.  The SET spec already facilitates that.

                                                                -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Thursday, May 18, 2017 11:41 AM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Dick Hardt <[email-masked]<mailto:[email-masked]>>; ID Events Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Dealing with issuer conflict

Mike,

Currently in the draft:

  "iss": "https://connect.myidp.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=kJ5Mfn6i39lorLgbbkC40kBC-Hfkom_nHJw9DvCTou8&e=>",

  "sub": "248289761001",

  "aud": ["connect.myidp.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JcMmHMLfNI_3lsrNceb6VM6dKMbZBX7-Urd_E6grwkg&e=>"],

  "iat": 1471566154,

  "jti": "bWJq",

  "events": {

    "http://schemas.openid.net/risc/event-type/account-deleted<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_risc_event-2Dtype_account-2Ddeleted&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=QHxJy7zqDzcRGhmcGhatA2k15bYULPODbW71Ztc4Kx4&e=>": {}

  }

}

{

  "iss": "https://exampleretail.store.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__exampleretail.store.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=YZax0bYIy8_J3nc40E5kAMdsqQpui6Slj4YZYqI7bFM&e=>",

  "sub": "248289761001",

  "aud": ["connect.myidp.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JcMmHMLfNI_3lsrNceb6VM6dKMbZBX7-Urd_E6grwkg&e=>"],

  "iat": 1471566154,

  "jti": "bWJq",

  "events": {

    "http://schemas.openid.net/risc/<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_risc_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JVaG5ee6BYf27emDyvsG749Ej4XX9d2FcKveRJ20ww8&e=>event-type/account-deleted": {

      "iss”:"connect.myidp.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JcMmHMLfNI_3lsrNceb6VM6dKMbZBX7-Urd_E6grwkg&e=>”

    }

  }

}

{

  "iss": "https://exampleretail.store.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__exampleretail.store.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=YZax0bYIy8_J3nc40E5kAMdsqQpui6Slj4YZYqI7bFM&e=>",

  "aud": ["connect.myidp.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JcMmHMLfNI_3lsrNceb6VM6dKMbZBX7-Urd_E6grwkg&e=>"],

  "iat": 1471566154,

  "jti": "bWJq",

  "events": {

    "http://schemas.openid.net/risc/event-type/account-deleted<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_risc_event-2Dtype_account-2Ddeleted&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=QHxJy7zqDzcRGhmcGhatA2k15bYULPODbW71Ztc4Kx4&e=>": {

      "iss”:”connect.myidp.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JcMmHMLfNI_3lsrNceb6VM6dKMbZBX7-Urd_E6grwkg&e=>”

      "sub": "248289761001",

    }

  }

}

OR, Alternative 2:

{

  "iss": "https://exampleretail.store.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__exampleretail.store.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=YZax0bYIy8_J3nc40E5kAMdsqQpui6Slj4YZYqI7bFM&e=>",

  "sub": "248289761001",

  "aud": ["connect.myidp.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JcMmHMLfNI_3lsrNceb6VM6dKMbZBX7-Urd_E6grwkg&e=>"],

  "iat": 1471566154,

  "jti": “bWJq"

  “subIss”:”connect.myidp.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JcMmHMLfNI_3lsrNceb6VM6dKMbZBX7-Urd_E6grwkg&e=>”,

  "events": {

    "http://schemas.openid.net/risc/event-type/account-deleted<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_risc_event-2Dtype_account-2Ddeleted&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=QHxJy7zqDzcRGhmcGhatA2k15bYULPODbW71Ztc4Kx4&e=>": {}

  }

}

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=1rw9A2hB-RR82vYgRNzhLmNcUkpJ6uyq4PFNDImb-78&e=>
[email-masked]<mailto:[email-masked]>

                                                                -- Mike

??

Phil

Thoughts?

Phil

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 18 May 2017 13:11:05 -0700

We also have the open issue of SETs being confused for Id Tokens or access
tokens.

Pushing the iss+sub pair always down to the event level, and leaving only
an iss at the top level solves both problems.

The top level iss is the issuer of the SET and provides context for the SET
signature.

The event level iss provides context for event level sub.

There is no top level sub, this eliminates any Id Token or access token
confusion possibility.

The only drawback I can see is the extra verbosity in case multiple events
are in one SET. Also, the top level iss and event level iss will probably
be the same often for SETs issued by an IdP, but they don't have to. But I
don't see this as a big problem.

This is the alternative I am referring to:
{

Marius

On Thu, May 18, 2017 at 12:34 PM, Phil Hunt (IDM) <[email-masked]>
wrote:

> Thanks Mike.
>
> I think we disagree.
>
> The concern I have is that most implementers will have to write code that
> always checks for the absence of a duplicate issuer claim because it
> changes the meaning of subject.
>
> This strikes me as complexity that needs to be dealt with in the core
> spec. It stems from our SecToken's use of JWT and its popular use today.
>
> Most of what you’re talking about seems to me to be decisions that can be
> made by particular event definitions or event family definitions.  I have
> no problem with particular events or event families employing some of the
> strategies that you’re describing.  The SET spec already facilitates that.
>
>
>
> But per previous discussions, we shouldn’t be making restrictions in the
> SET spec that limit its applicability by making restrictions on claims
> usage that will only work for some event use cases and will rule out
> others.  We should hold to the bright-line test that event definitions
> define what claims are included in SETS (other than the “events” claim
> itself) and how they’re used.  Intruding on that will unnecessarily limit
> the applicability of SETs.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Phil Hunt [mailto:[email-masked] <[email-masked]>]
> *Sent:* Thursday, May 18, 2017 11:41 AM
> *To:* Mike Jones <[email-masked]>
> *Cc:* Dick Hardt <[email-masked]>; ID Events Mailing List <
> [email-masked]>
>
> *Subject:* Re: [Id-event] Dealing with issuer conflict
>
>
>
> Mike,
>
>
>
>   "iss": "https://connect.myidp.com <https://urldefense.proofpoint.com/v2/url?u=https-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=kJ5Mfn6i39lorLgbbkC40kBC-Hfkom_nHJw9DvCTou8&e=>",
>
>   "sub": "248289761001",
>
>   "aud": ["connect.myidp.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JcMmHMLfNI_3lsrNceb6VM6dKMbZBX7-Urd_E6grwkg&e=>"],
>
>   "iat": 1471566154,
>
>   "jti": "bWJq",
>
>   "events": {
>
>     "*http://schemas.openid.net/risc/event-type/account-deleted <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_risc_event-2Dtype_account-2Ddeleted&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=QHxJy7zqDzcRGhmcGhatA2k15bYULPODbW71Ztc4Kx4&e=>*": {}
>
>   }
>
> }
>
>
>
>   "iss": "https://exampleretail.store.com <https://urldefense.proofpoint.com/v2/url?u=https-3A__exampleretail.store.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=YZax0bYIy8_J3nc40E5kAMdsqQpui6Slj4YZYqI7bFM&e=>",
>
>   "sub": "248289761001",
>
>   "aud": ["connect.myidp.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JcMmHMLfNI_3lsrNceb6VM6dKMbZBX7-Urd_E6grwkg&e=>"],
>
>   "iat": 1471566154,
>
>   "jti": "bWJq",
>
>   "events": {
>
>     "*http://schemas.openid.net/risc/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_risc_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JVaG5ee6BYf27emDyvsG749Ej4XX9d2FcKveRJ20ww8&e=>event-type/account-deleted*": {
>
>       "iss”:"connect.myidp.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JcMmHMLfNI_3lsrNceb6VM6dKMbZBX7-Urd_E6grwkg&e=>”
>
>     }
>
>   }
>
> }
>
>
>
> If you are writing code, if you agree that the OP issues a lot of events,
> you end up having to check that there’s no embedded “iss” present before
> you can assume the issuer of the subject is the same as that of the SET
> token.  This strikes me as very complex.
>
>
>
> Any “sub” at the top-level (if any) should be associated with the “iss” at
> the top-level, which is always the event issuer.
>
>
>
>   "iss": "https://exampleretail.store.com <https://urldefense.proofpoint.com/v2/url?u=https-3A__exampleretail.store.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=YZax0bYIy8_J3nc40E5kAMdsqQpui6Slj4YZYqI7bFM&e=>",
>
>   "aud": ["connect.myidp.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JcMmHMLfNI_3lsrNceb6VM6dKMbZBX7-Urd_E6grwkg&e=>"],
>
>   "iat": 1471566154,
>
>   "jti": "bWJq",
>
>   "events": {
>
>     "*http://schemas.openid.net/risc/event-type/account-deleted <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_risc_event-2Dtype_account-2Ddeleted&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=QHxJy7zqDzcRGhmcGhatA2k15bYULPODbW71Ztc4Kx4&e=>*": {
>
>       "iss”:”connect.myidp.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JcMmHMLfNI_3lsrNceb6VM6dKMbZBX7-Urd_E6grwkg&e=>”
>
>       "sub": "248289761001",
>
>     }
>
>   }
>
> }
>
>
>
> OR, Alternative 2:
>
> {
>
>   "iss": "https://exampleretail.store.com <https://urldefense.proofpoint.com/v2/url?u=https-3A__exampleretail.store.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=YZax0bYIy8_J3nc40E5kAMdsqQpui6Slj4YZYqI7bFM&e=>",
>
>   "sub": "248289761001",
>
>   "aud": ["connect.myidp.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JcMmHMLfNI_3lsrNceb6VM6dKMbZBX7-Urd_E6grwkg&e=>"],
>
>   "iat": 1471566154,
>
>   "jti": “bWJq"
>
>   “subIss”:”connect.myidp.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__connect.myidp.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=JcMmHMLfNI_3lsrNceb6VM6dKMbZBX7-Urd_E6grwkg&e=>”,
>
>   "events": {
>
>     "*http://schemas.openid.net/risc/event-type/account-deleted <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_risc_event-2Dtype_account-2Ddeleted&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=QHxJy7zqDzcRGhmcGhatA2k15bYULPODbW71Ztc4Kx4&e=>*": {}
>
>   }
>
> }
>
>
>
> I can see pros and cons for either. I like option 1 because it also makes
> the SET different from ID Tokens and Access Tokens.
>
>
>
> The best way to define this is to enforce that sub may only be used at the
> top level if it is globally identifiable (e.g. such as in the case of SCIM
> URIs).
>
>
>
> Phil
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ZRxoy6LboCUVOSdvaKuUa2q0bYlGv-xBKQr_PYRO1Hg&s=1rw9A2hB-RR82vYgRNzhLmNcUkpJ6uyq4PFNDImb-78&e=>
>
> [email-masked]
>
>
>
> I believe that the solution already discussed is the best one.  If the
> event issuer is different than a logical issuer associated with the event
> subject, then put the logical “iss” and “sub” values inside the event.  Any
> “sub” at the top-level (if any) should be associated with the “iss” at the
> top-level, which is always the event issuer.
>
>
>
> Any proposal that requires duplicating information, such as requiring
> “subIss” even when it’s always identical to “iss”, is not a great
> architectural choice, since it creates unnecessary error conditions that
> would not otherwise be possible.  (How should implementations handle the
> case where two values are required to match but don’t?)
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Id-event [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Phil Hunt (IDM)
> *Sent:* Thursday, May 18, 2017 7:31 AM
> *To:* Dick Hardt <[email-masked]>
> *Cc:* ID Events Mailing List <[email-masked]>
> *Subject:* Re: [Id-event] Dealing with issuer conflict
>
>
>
> ??
>
>
>
> In Connect, since sub is not uniquely identified, the iss for the sub must
> be included. This creates a conflict if the issuer of the SET is not the
> issuer of the subject.
>
>
>
> In RISC we were discussing account close events. I am assume one of the
> scenarios is RPs will notify IDPs when they close an account. They must use
> an iss not associated with sub. As things stand now, they will have to
> assert the extra iss value in their payload---which for most events is
> complex to parse since their are no other extra claims.
>
>
>
> Phil
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=p1Vsd1Hb7BX87sV4x9MhtsGbORcuiacHxujwThSnWh4&s=ATYzOXXGto5afit3OgTjh19KczxKCvaBwC7ftofHMrs&e=>
>
> --
>
> Subscribe to the HARDTWARE
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=p1Vsd1Hb7BX87sV4x9MhtsGbORcuiacHxujwThSnWh4&s=NGbCAfBEl5TtskWdjjWOY2cQJA3Fsy9QvntPnstyIkc&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=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=
> p1Vsd1Hb7BX87sV4x9MhtsGbORcuiacHxujwThSnWh4&s=
> ATYzOXXGto5afit3OgTjh19KczxKCvaBwC7ftofHMrs&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=
> 8LfCYox0y3ghN8YAXLrAb5zfUt5rVD8vbwKwvw8-Rjk&s=gv4-yN8LDVir82WEWzix61-
> YzkrfquEPKMk_TtLylrw&e=
>
>
>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 18 May 2017 13:19:40 -0700

Mike

The RISC group case is a useful case to discuss here since we need to understand how SETs will be used. 

AFAIK, the RISC WG is assuming the issue of iss conflict will be resolved in SECEVENTs. 

My understanding is this is much more than registering an event claim but to get to interoperable event formats that can be used by many downstream SDOs and WGs. 

Maybe I am mistaken?

Phil

> On May 18, 2017, at 12:46 PM, Mike Jones <[email-masked]> wrote:
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 18 May 2017 13:29:56 -0700

Marius,

+1

I like this because my point has been re-using iss at the top level may be visually pleasing but it doesn't make the code simpler. Those that fail to check for an embedded iss could be exposing themselves to mistaken assumptions about the subject issuer causing confusion. 

IMO, this proposal can work equally well for the SCIM cases too. 

Phil

> On May 18, 2017, at 1:11 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> We also have the open issue of SETs being confused for Id Tokens or access tokens.
> 
> Pushing the iss+sub pair always down to the event level, and leaving only an iss at the top level solves both problems.
> 
> The top level iss is the issuer of the SET and provides context for the SET signature.
> 
> There is no top level sub, this eliminates any Id Token or access token confusion possibility.
> 
> The only drawback I can see is the extra verbosity in case multiple events are in one SET. Also, the top level iss and event level iss will probably be the same often for SETs issued by an IdP, but they don't have to. But I don't see this as a big problem.
> 
>> On Thu, May 18, 2017 at 12:34 PM, Phil Hunt (IDM) <[email-masked]> wrote:
>> Thanks Mike. 
>> 
>> I think we disagree.
>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 May 2017 20:35:26 +0000

This can all be really simple.  If an event is defined such that an “iss” value is needed as part of identifying the subject of the SET that can be distinct from the issuing “iss”, then it needs to be inside the event payload.  Whereas, if an event is defined such that its issuer is always aligned with the subject, then they’re never a need for an inner “iss”, in which case it must be omitted.  The spec already gives appropriate guidance along these lines.

In both cases, there’s never an optional inner “iss” for an event.  Either the event definition requires the inner “iss” or the event definition precludes it.  There’s no special-case parsing of optional inner “iss” values in either case.

                                                                -- Mike

Sent: Thursday, May 18, 2017 1:20 PM

Mike

Maybe I am mistaken?

Phil

On May 18, 2017, at 12:46 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
In many use cases, only SETs from a single event family will be legal and all will use the same claims conventions.  In that case, a normal JWT parser will likely be used and the application will process the additional event-specific claims.  There’s no general-purpose SET parser in the mix.

                                                                -- Mike

Thanks Mike.

I think we disagree.

Phil

                                                                -- Mike

Mike,

Currently in the draft:

  "sub": "248289761001",

  "iat": 1471566154,

  "jti": "bWJq",

  "events": {

  }

}

{

  "sub": "248289761001",

  "iat": 1471566154,

  "jti": "bWJq",

  "events": {

    }

  }

}

{

  "iat": 1471566154,

  "jti": "bWJq",

  "events": {

      "sub": "248289761001",

    }

  }

}

OR, Alternative 2:

{

  "sub": "248289761001",

  "iat": 1471566154,

  "jti": “bWJq"

  "events": {

  }

}

Phil

                                                                -- Mike

??

Phil

Thoughts?

Phil