Subject: [Id-event] Summarizing recent discussions on ID-Event token draft

From: Phil Hunt <[email-masked]>
Date: Tue, 9 Aug 2016 10:18:38 -0700

I thought I would update the list on some discussions that have been happening over in the OpenID Connect and RISC working groups conference calls.

These discussions have been about the core spec and the role of “top-level” attributes vs. event “extension” attributes. 
See: https://tools.ietf.org/html/draft-hunt-idevent-token-01

In particular should “sub” be used in the top level to “point” to the subject (in the broader english sense) of the event, or should it be constrained to the SAML/ID Token definition which is the authenticated user.  

Taken in the narrower definition, it is important to observe that in an ID Token, “sub” and “iss” go together.  The issuer provides the context for the authenticated subject identifier. The problem with events, is that it might not be the AS (or OP) which is issuing the event.  

To summarize a fair amount of discussion, the feeling seems to be the following:

*  The Event Token top level attributes should be fairly limited and not include the sub attribute.  
*  For events that are about a user, the relevant event specification may include a “sub” attribute within the event’s sub-object and not in the top-level. Further that sub-object can also include the issuer of the user.  
* The top-level “iss” shall mean the issuer of the event where the state change occurred.
*  “sub” should not be present in the top level structure.  Also, “events” must also be present.

Here would be a new example logout:
{
  <— top level is about the event itself ->
  "iss": "https://server.example.com",
  "aud": "s6BhdRkqt3",
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": [
    "https://specs.openid.net/logout <https://specs.openid.net/logout>"
  ],
  "https://specs.openid.net/logout <https://specs.openid.net/logout>": {
    <- This level is defined entirely by the event URI->
    "iss": "https://oidc.example.com",
    “jti": "08a5019c-17e1-4977-8f42-65a12843ea02”,
    "sub": "248289761001”,
    “exp”: <ID token expiry>
  }
}

In the above example note that the “event” object can have its own iss and subject (sub or jti) that have meaning within the context of an OpenID OP provider.  The issuer of the event can be different (the top-level) and represents the entity that signs the event (if it is signed).

The top-level attributes identify an individual event and are used to validate the event (signing etc).  Where as the nested object contains all of the data about the event and is defined by the profiling specification (e.g. a possible OpenID Logout Event spec).  In this case, in OpenID, logging out usually translates into revoking an ID Token. Thus the “jti” for the ID token (08a5019c...843ea02) is included in the Logout object.

Side note.  Regarding “logout”, it might be useful to include the expiry of the ID Token in case the subscriber has not yet received an ID Token. This would let the subscriber know how long it needs to keep the revocation information for.  IOW…after the the ID Token is expired, the subscriber would no longer need to track the revocation state.

It is also good to observe that the “aud” at the top level describes the subscriber of the event.  This may also be different then the original audience of the ID Token.

So to conclude. By making top-level attributes strictly about the events own validation, and nested objects about the event, we avoid collisions in definitions such as the issuer of the event, vs. the original issuer of a security assertion.

I hope I’ve gotten everyone’s feedback correct here. Lets continue to discuss. I will revise the draft to follow the groups thinking here.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

---

From: Mike Jones <[email-masked]>
Date: Tue, 9 Aug 2016 18:54:39 +0000

Thanks for writing this, Phil.  Unfortunately, the summary below does not include my feedback, which at the essence, is to keep the ID Events data structure as simple and general-purpose as possible.  (I strongly believe that JWT is the success it is because we made JWT as simple and general-purpose as possible, and we should follow this successful example and do the same here.)

I believe that the ID Events spec needs to include these things, and these things only:

·       Define of the “events” claim

·       Define that an event name can be used as a top-level claim

·       Require that “iss” be included and that the JWT be signed by the issuer

·       Include a statement along the lines of “The claims to be included with any particular event are to be defined by the event”

And I’d stop there.

It should be entirely up to applications to say what claims are included with events they define and what their format and meanings are.  Then the ID Events spec will be as general-purpose as possible, with it being natural for it to be used in essentially all JSON Event contexts.

As soon as we start putting restrictions on the use of particular claims by events, we’re making the ID Events spec less general-purpose and less natural to use.  In particular, the only thing that the spec should say about the “sub” claim is that “Like all other claims other than ‘events’ and ‘iss’, whether the ‘sub’ claim is to be included with an event is entirely event-specific.  The claims to be included with any particular event are explicitly outside the scope of this specification.”

                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Tuesday, August 9, 2016 10:19 AM
To: [email-masked]
Subject: [Id-event] Summarizing recent discussions on ID-Event token draft

{

  "aud": "s6BhdRkqt3",

  "iat": 1458668180,

  "exp": 1458668580,

  "events": [

    "https://specs.openid.net/logout"

  ],

  "https://specs.openid.net/logout": {

    "sub": "248289761001”,

    “exp”: <ID token expiry>

  }

}

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 9 Aug 2016 12:06:44 -0700

I didn’t cover this as I didn’t want to confuse people with too many things.

But I think we agree on all of the below.

I’m not sure that we need a “name”. What is your intention there.

Phil

@independentid

> On Aug 9, 2016, at 11:54 AM, Mike Jones <[email-masked]> wrote:
> 
>   <>
> See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 <https://tools.ietf.org/html/draft-hunt-idevent-token-01>
>  
>   "iss": "https://server.example.com <https://server.example.com/>",
>   "aud": "s6BhdRkqt3",
>     "iss": "https://oidc.example.com <https://oidc.example.com/>",
> www.independentid.com <http://www.independentid.com/>
> [email-masked] <mailto:[email-masked]>

---

From: Mike Jones <[email-masked]>
Date: Tue, 9 Aug 2016 19:12:54 +0000

I’m glad to hear that we agree on keeping it as simple and general-purpose as possible and that you agree with my write-up.  I think we then have a good path forward.

I’m not sure what you mean by “I’m not sure that we need a “name”. What is your intention there.”  The only place I used the word “name” was in my statement “Define that an event name can be used as a top-level claim”.  What I was trying to get at is was that if “http://specs.openid.net/logout” is used as an event name, that it can also be used as a claim name in the JWT containing information about the event.  (Maybe I’m not using the correct terminology, hence the unintended confusion ☺.)

                                                       Thanks again,
                                                       -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Tuesday, August 9, 2016 12:07 PM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft

Phil

@independentid

On Aug 9, 2016, at 11:54 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

I believe that the ID Events spec needs to include these things, and these things only:
•       Define of the “events” claim
•       Define that an event name can be used as a top-level claim
•       Require that “iss” be included and that the JWT be signed by the issuer
•       Include a statement along the lines of “The claims to be included with any particular event are to be defined by the event”

And I’d stop there.

                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Tuesday, August 9, 2016 10:19 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Id-event] Summarizing recent discussions on ID-Event token draft

{

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

  "aud": "s6BhdRkqt3",

  "iat": 1458668180,

  "exp": 1458668580,

  "events": [

  ],

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

    "sub": "248289761001”,

    “exp”: <ID token expiry>

  }

}

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 9 Aug 2016 12:39:59 -0700

I was referring to this in your email
"Define that an event name can be used as a top-level claim”

Is this different from the event uri?

Phil

@independentid

> On Aug 9, 2016, at 12:12 PM, Mike Jones <[email-masked]> wrote:
> 
> I’m not sure what you mean by “I’m not sure that we need a “name”. What is your intention there.”  The only place I used the word “name” was in my statement “Define that an event name can be used as a top-level claim”.  What I was trying to get at is was that if “http://specs.openid.net/logout <http://specs.openid.net/logout>” is used as an event name, that it can also be used as a claim name in the JWT containing information about the event.  (Maybe I’m not using the correct terminology, hence the unintended confusion J.)
>  
>                                                        Thanks again,
>                                                        -- Mike
>   <>
> On Aug 9, 2016, at 11:54 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Phil Hunt
> To: [email-masked] <mailto:[email-masked]>
> _______________________________________________
> Id-event mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 9 Aug 2016 16:14:51 -0700

Mike, are you suggesting that a sub claim can only show up at the event
level and not at the top level:

In particular, the only thing that the spec should say about the “sub”
> claim is that “Like all other claims other than ‘events’ and ‘iss’, whether
> the ‘sub’ claim is to be included with an event is entirely event-specific.

A top level sub and multiple events are incompatible IMO.

Do we have a compelling reason to support multiple events per message?

Marius

On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <[email-masked]> wrote:

> www.independentid.com
> [email-masked]
> I’m glad to hear that we agree on keeping it as simple and general-purpose
> as possible and that you agree with my write-up.  I think we then have a
> good path forward.
>
> I’m not sure what you mean by “I’m not sure that we need a “name”. What
> is your intention there.”  The only place I used the word “name” was in
> my statement “Define that an event name can be used as a top-level claim”.
> What I was trying to get at is was that if “http://specs.openid.net/logout”
> is used as an event name, that it can also be used as a claim name in the
> JWT containing information about the event.  (Maybe I’m not using the
> correct terminology, hence the unintended confusion J.)
>
>                                                        Thanks again,
>                                                        -- Mike
>
> *From:* Phil Hunt [mailto:[email-masked] <[email-masked]>]
> *Sent:* Tuesday, August 9, 2016 12:07 PM
> *To:* Mike Jones <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event
> token draft
>
> www.independentid.com
> [email-masked]
> Thanks for writing this, Phil.  Unfortunately, the summary below does not
> include my feedback, which at the essence, is to keep the ID Events data
> structure as simple and general-purpose as possible.  (I strongly believe
> that JWT is the success it is because we made JWT as simple and
> general-purpose as possible, and we should follow this successful example
> and do the same here.)
>
> ·       Include a statement along the lines of “The claims to be included
> with any particular event are to be defined by the event”
>
> And I’d stop there.
>
> It should be entirely up to applications to say what claims are included
> with events they define and what their format and meanings are.  Then the
> ID Events spec will be as general-purpose as possible, with it being
> natural for it to be used in essentially all JSON Event contexts.
>
> As soon as we start putting restrictions on the use of particular claims
> by events, we’re making the ID Events spec less general-purpose and less
> natural to use.  In particular, the only thing that the spec should say
> about the “sub” claim is that “Like all other claims other than ‘events’
> and ‘iss’, whether the ‘sub’ claim is to be included with an event is
> entirely event-specific.  The claims to be included with any particular
> event are explicitly outside the scope of this specification.”
>
>                                                        -- Mike
>
> *From:* Id-event [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Phil Hunt
> *Sent:* Tuesday, August 9, 2016 10:19 AM
> *To:* [email-masked]
> *Subject:* [Id-event] Summarizing recent discussions on ID-Event token
> draft
>
> I thought I would update the list on some discussions that have been
> happening over in the OpenID Connect and RISC working groups conference
> calls.
>
> These discussions have been about the core spec and the role of
> “top-level” attributes vs. event “extension” attributes.
> In particular should “sub” be used in the top level to “point” to the
> subject (in the broader english sense) of the event, or should it be
> constrained to the SAML/ID Token definition which is the authenticated
> user.
>
> Taken in the narrower definition, it is important to observe that in an ID
> Token, “sub” and “iss” go together.  The issuer provides the context for
> the authenticated subject identifier. The problem with events, is that it
> might not be the AS (or OP) which is issuing the event.
>
> *  For events that are about a user, the relevant event specification may
> include a “sub” attribute within the event’s sub-object and not in the
> top-level. Further that sub-object can also include the issuer of the user.
>
> In the above example note that the “event” object can have its own iss and
> subject (sub or jti) that have meaning within the context of an OpenID OP
> provider.  The issuer of the event can be different (the top-level) and
> represents the entity that signs the event (if it is signed).
>
> The top-level attributes identify an individual event and are used to
> validate the event (signing etc).  Where as the nested object contains all
> of the data about the event and is defined by the profiling specification
> (e.g. a possible OpenID Logout Event spec).  In this case, in OpenID,
> logging out usually translates into revoking an ID Token. Thus the “jti”
> for the ID token (08a5019c...843ea02) is included in the Logout object.
>
> Side note.  Regarding “logout”, it might be useful to include the expiry
> of the ID Token in case the subscriber has not yet received an ID Token.
> This would let the subscriber know how long it needs to keep the revocation
> information for.  IOW…after the the ID Token is expired, the subscriber
> would no longer need to track the revocation state.
>
> It is also good to observe that the “aud” at the top level describes the
> subscriber of the event.  This may also be different then the original
> audience of the ID Token.
>
> So to conclude. By making top-level attributes strictly about the events
> own validation, and nested objects about the event, we avoid collisions in
> definitions such as the issuer of the event, vs. the original issuer of a
> security assertion.
>
> I hope I’ve gotten everyone’s feedback correct here. Lets continue to
> discuss. I will revise the draft to follow the groups thinking here.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 9 Aug 2016 16:25:51 -0700

Probably not. There is a reason to say that multiple related events could be in the same message. 

For example a scim acnt reset and a risc reset. 

Thought it doesn't have to be that way. 

More likely adding extensions might be important later on. Eg to provide classification or proprietary signaling needs. 

Phil

> On Aug 9, 2016, at 4:14 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> Mike, are you suggesting that a sub claim can only show up at the event level and not at the top level:
> 
>> In particular, the only thing that the spec should say about the “sub” claim is that “Like all other claims other than ‘events’ and ‘iss’, whether the ‘sub’ claim is to be included with an event is entirely event-specific.
> 
>>> I’m not sure what you mean by “I’m not sure that we need a “name”. What is your intention there.”  The only place I used the word “name” was in my statement “Define that an event name can be used as a top-level claim”.  What I was trying to get at is was that if “http://specs.openid.net/logout” is used as an event name, that it can also be used as a claim name in the JWT containing information about the event.  (Maybe I’m not using the correct terminology, hence the unintended confusion J.)
>>>  
>>>                                                        Thanks again,
>>>                                                        -- Mike
>>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 11 Aug 2016 11:54:15 +0000

No, I’m not saying that “sub” cannot appear at the top level.  I’m saying that “sub” will only occur at the top level if the particular event defines that “sub” is used in that way for that event.

There are probably use cases for multiple events per message but I doubt there are use cases for multiple *unrelated* events per message.  By definition, related events that use top-level claims would need to use them in a compatible way.  I don’t see that as being a problem.

That being said, the predominant use case is likely to be a single event per JWT.

                                                                     -- Mike

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Tuesday, August 9, 2016 7:15 PM
To: Phil Hunt <[email-masked]>
Cc: Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft

Marius

On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
I was referring to this in your email
"Define that an event name can be used as a top-level claim”

Phil

@independentid

On Aug 9, 2016, at 12:12 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                       Thanks again,
                                                       -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Tuesday, August 9, 2016 12:07 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft

Phil

@independentid

And I’d stop there.

                                                       -- Mike

{

  "aud": "s6BhdRkqt3",

  "iat": 1458668180,

  "exp": 1458668580,

  "events": [

  ],

    "sub": "248289761001”,

    “exp”: <ID token expiry>

  }

}

Phil

@independentid

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 11 Aug 2016 06:39:44 -0700

I think using sub at the top level leads to complexity. Eg Can you provide a rule for when top level is used or not by an individual spec?  IMO. Top level should always be used the same way by all implementers. 

Based on the calls at risc/connect, we discussed that it would be best to move all event specifics to the event object area. This way different events can have different event addressing (eg sub/iss, uri, jit/iss). When iss is needed to uniquely qualify a sub, it can be provided without conflicting with the issuer of the event. Similarly jti and iss can be used for a revoked token without conflicting with the event jti. 

I plan to post a new draft shortly that will give some examples based on feedback from the openid risc/connect discussions.

We can always change again. 

Phil

> On Aug 11, 2016, at 4:54 AM, Mike Jones <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 11 Aug 2016 15:03:27 +0000

The simple rule is that if the particular event calls for the “sub” claim to be at the top level, then it is.  This is no different from any other claim that an event might place at the top level.

The complexity arises if “sub” is unnecessarily special-cased.  We shouldn’t do that, because it limits the applicability of the specification.

                                                       -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked]]
Sent: Thursday, August 11, 2016 9:40 AM
To: Mike Jones <[email-masked]>
Cc: Marius Scurtescu <[email-masked]>; [email-masked]
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft

Phil

On Aug 11, 2016, at 4:54 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
No, I’m not saying that “sub” cannot appear at the top level.  I’m saying that “sub” will only occur at the top level if the particular event defines that “sub” is used in that way for that event.

                                                                     -- Mike

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Tuesday, August 9, 2016 7:15 PM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft

Marius

Phil

@independentid

                                                       Thanks again,
                                                       -- Mike

Phil

@independentid

And I’d stop there.

                                                       -- Mike

{

  "aud": "s6BhdRkqt3",

  "iat": 1458668180,

  "exp": 1458668580,

  "events": [

  ],

    "sub": "248289761001”,

    “exp”: <ID token expiry>

  }

}

Phil

@independentid

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 11 Aug 2016 08:26:15 -0700

How do you resolve the conflict that arises around iss since iss must be the entity that signed the event and will often not be the one that issued the original idtoken in the case of openid(and which uniquely qualifies sub). 

Phil

> On Aug 11, 2016, at 8:03 AM, Mike Jones <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 11 Aug 2016 15:52:52 +0000

In the OpenID Connect Back-Channel Logout case, this conflict, by definition, can never occur.  One of the validation rules for the logout event is that it MUST be signed by the identity provider – the same party that issued the ID Token at authentication time.  Otherwise, it’s likely part of an attack, and must be discarded.

Yes, there are other use cases in which multiple parties might sign different JWTs in an application context.  Yes, in those cases, more complex event data structures might be needed.  But in the back-channel logout case, there’s exactly one issuer and one subject, which MUST match those in the previously issued ID Token.

It’s an intentionally very simple use case.

                                                       -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked]]
Sent: Thursday, August 11, 2016 11:26 AM
To: Mike Jones <[email-masked]>
Cc: [email-masked]; Marius Scurtescu <[email-masked]>
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft

Phil

On Aug 11, 2016, at 8:03 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
The simple rule is that if the particular event calls for the “sub” claim to be at the top level, then it is.  This is no different from any other claim that an event might place at the top level.

                                                       -- Mike

Cc: Marius Scurtescu <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Phil

                                                                     -- Mike

Marius

Phil

@independentid

                                                       Thanks again,
                                                       -- Mike

Phil

@independentid

And I’d stop there.

                                                       -- Mike

{

  "aud": "s6BhdRkqt3",

  "iat": 1458668180,

  "exp": 1458668580,

  "events": [

  ],

    "sub": "248289761001”,

    “exp”: <ID token expiry>

  }

}

Phil

@independentid

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 11 Aug 2016 08:59:55 -0700

How do you resolve conflicts on iss then?  The top level has to be the issuer of the event as the issuer signs. 

If one spec can use it all must be able to. I believe you previously objected to that saying sub must be as how id tokens define them. But that isnt unique and requires iss. Now we would have sub at the top with an event issuer at the top and a sub issuer in the extension. That seems incredibly complex not to mention awkward. 

If we make sub a uri for all then it can work ass iss from id token would not be needed. But i can see many objecting to the change in format. 

Why not have a logout be an event with an id token attached for example?

Phil

---

From: Justin Richer <[email-masked]>
Date: Thu, 11 Aug 2016 12:09:48 -0400

I disagree with special-casing logout like this. The “iss” at the root of the event should be the issuer of the event itself, always. The event sub-construct might also have that field, or it might inherit the global field if another value doesn’t exist for the sub-object if you want to get fancy. But in neither case is it putting a value into the root of the object.

If you want to attach a full ID token, you should do that as a data member, in my opinion. You can do that either by using the JSON object payload as a sub-object or by doing it as the serialized compact form as a string (if for some reason you need to keep that signature as well). I’d prefer the former case in most instances since the issuer of the event should be authoritative for the event it’s describing.

 — Justin

> On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) <[email-masked]> wrote:
> 
> On Aug 11, 2016, at 8:03 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
>> Cc: Marius Scurtescu <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> On Aug 11, 2016, at 4:54 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: Marius Scurtescu [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Phil Hunt <[email-masked] <mailto:[email-masked]>>
>> Cc: Mike Jones <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>> On Aug 9, 2016, at 12:12 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> From: Phil Hunt [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>_______________________________________________
> Id-event mailing list
> [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Thu, 11 Aug 2016 16:09:58 +0000

I don’t know why you’re writing about conflicts on “iss” because, as I explained below, for the event in question, “iss” conflicts, by definition, may not occur.  I think you’re confused as to what I’m discussing, because there certainly would be only one “iss” and one “sub” in the event JWT – both at the top level.  There’s no duplication (and none needed!).  To remove any ambiguity from the discussion, an example of what this might look like is:

{
  "iss": "https://server.example.com",
  "aud": "s6BhdRkqt3",
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "sub": "248289761001",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": [
    "https://specs.openid.net/logout"
  ],
  "sid": "08a5019c-17e1-4977-8f42-65a12843ea02"
}

This contains all information needed for the Identity Provider to unambiguously and securely convey that the RP is to log out the party identified by the issuer and the subject (and in this case, also qualified with the session ID).  It doesn’t have to get any more complicated than this.

                                                       -- Mike

Sent: Thursday, August 11, 2016 12:00 PM

Phil

                                                       -- Mike

Phil

                                                                     -- Mike

Marius

Phil

@independentid

                                                       Thanks again,
                                                       -- Mike

Phil

@independentid

And I’d stop there.

                                                       -- Mike

{

  "aud": "s6BhdRkqt3",

  "iat": 1458668180,

  "exp": 1458668580,

  "events": [

  ],

    "sub": "248289761001”,

    “exp”: <ID token expiry>

  }

}

Phil

@independentid

---

From: John Bradley <[email-masked]>
Date: Thu, 11 Aug 2016 12:22:24 -0400

Not surprisingly a multipurpose message format will not be as optimized as a single purpose one.

Connect itself doesn’t really have a conflict around issuer the same entity sending the logout message is always the one that created the id_token that it refers to.

Using the same format as id_token with the same semantics to identify the thing to be terminated makes sense from a purely openID Connect point of view.

Oter messages that have different notions of subject and are issued by different parties than the one that controls the subject cause issues when you try and fit them into the same format as an ID_Token, I grant you that.

It was mentioned that we need to differentiate between these events and id_tokens.  Mostly we need to do that in cases where the token might be presented in the front channel.

To do that se do have mandatory claims for nonce and c_hash or at_hash as well as the addition of events parameter to reduce confusion.   Now I admit that some people may still get that wrong,  and the removal of sub from the top level would remove any concern.  However Mike has a point that adoption may be hurt if we change the semantics too much.

I don’t see backchannel single logout being used by many social login RP, it is a lot of work to maintain server side state.   It is mostly an enterprise and large site sort of feature.
That may or may not impact on if it is better to be simple and aligned with connect’s id token or more general purpose to fit with other enterprise to SaaS features like SCIM events.

I think the two directions lead to different formats.   

The compromise of special casing Connect SLO and bodging the formats together is probably the worst option.

John B.

---

From: Mike Jones <[email-masked]>
Date: Thu, 11 Aug 2016 16:32:42 +0000

See my previous message, John, which was a reply to Phil’s message that you also replied to, that contained a logout claims example.  I’m not proposing to special-case the Connect Logout message in any way.  The “iss” is the event issuer.  The other claims in the message are those defined by the event to be included, just like those for any other event.  Yes, the logout message doesn’t include a second issuer, a second subject, an ID Token as a claim, or anything else complicated like that, because those things aren’t needed for the logout use case.

As I’d written previously, the ID Events spec should define the “events” claim, how to use an event name as a claim (when needed), and say that the event JWT must be signed by the issuer, and stop there.  Trying to micro-manage claims usage within an event will only result in the ID Events spec being harder to use.  If we’d tried to similarly micro-manage JWT claims usage, JWT would likely not have been the success that it is.

                                                       -- Mike

From: John Bradley [mailto:[email-masked]]
Sent: Thursday, August 11, 2016 12:22 PM
To: Phil Hunt (IDM) <[email-masked]>
Cc: Mike Jones <[email-masked]>; [email-masked]; Marius Scurtescu <[email-masked]>; [email-masked] Ab <[email-masked]>
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft

John B.

On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:

Phil

                                                       -- Mike

Phil

                                                                     -- Mike

Marius

Phil

@independentid

                                                       Thanks again,
                                                       -- Mike

Phil

@independentid

And I’d stop there.

                                                       -- Mike

{

  "aud": "s6BhdRkqt3",

  "iat": 1458668180,

  "exp": 1458668580,

  "events": [

  ],

    "sub": "248289761001”,

    “exp”: <ID token expiry>

  }

}

Phil

@independentid

---

From: Phil Hunt <[email-masked]>
Date: Thu, 11 Aug 2016 09:49:20 -0700

Mike, 

Speaking as editor the format you propose ONLY works if “sub” becomes a URI so that all event specs can use it.  Otherwise, OIDC becomes a special case which really kills the point of this work. It also makes the specification much much more complex. Maybe it is just me, but a complex spec generally implies complex implementation too.

If you want sub at the top level, that would mean that the OIDC spec format would have to look like:
{
  "iss": "https://event.example.com <https://event.example.com/>",
  "aud": "s6BhdRkqt3",
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "sub": “https://token.example.com/248289761001",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": [
    "https://specs.openid.net/logout <https://specs.openid.net/logout>"
  ],
  "sid": "08a5019c-17e1-4977-8f42-65a12843ea02"
}

Given that events are signed (or should be), I will object strongly within the OIDF that the event issuer and the token issuer MUST be the same or that OIDF adopt a different format. Yes having iss be the same is a nice security convenience, but it imposes the architecture restriction that it be the same server.  At scale, delivery of events may become a problem for large scale providers if they are also delivering tokens to relying parties. The restriction isn’t really justified given the crypto alternative — which was the whole point of using JWT in the first place.

Per Justin’s comment, it seems elegant/trivial that a logout event simply has logout at the top level and an ID Token attached (though it might convey a lot of unneeded claims).  IMO, the OIDC logout spec should only convey the ID Token JTI.  It is going to be rare that you log out all devices for a user.  To most users, it means clear SSO within this browser only!  One can argue that clearing all devices/sessions is a different event entirely. It is an account reset or lock-out action.

Phil

@independentid

> On Aug 11, 2016, at 9:32 AM, Mike Jones <[email-masked]> wrote:
> 
> On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 11 Aug 2016 17:01:58 +0000

You’re aware that forcing “sub” to be a URI is a breaking change for most implementations, right?  This is hardly a way to encourage adoption!

The thing you wrote below that makes me think that you’re thinking about the purpose of the ID Events spec differently than me is this: “so that all event specs can use it”.  The purpose of the logout event *isn’t* for all event specs to use it.  It’s for the logout use case to use it.  There’s no expectation that events intended for one use case will even be comprehensible in other use cases because they won’t understand the contents of the event.  We shouldn’t drive any of the design by trying to achieve that unachievable goal, since events will *always* contain information that’s specific to their use case.

You’re making complexity arguments, whereas you’re also proposing more complex rules than I am (at least as I see it).  Trying to restrict the use of “sub” (or any other claims) is unneeded complexity.

I understand that you see things differently.  I hope you’ll nonetheless think about my argument that having fewer rules about claims usage in events will make them simpler.  I passionately care about keeping this simple, which is why I’m investing my time in this discussion.  If it’s simple, it will likely get widely used.

I’m going to sign out of the discussion for now because my wife is about to get out of surgery.  I hope you have a good day.

                                                       -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Thursday, August 11, 2016 12:49 PM
To: Mike Jones <[email-masked]>
Cc: John Bradley <[email-masked]>; [email-masked] Ab <[email-masked]>; [email-masked]; Marius Scurtescu <[email-masked]>
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft

Mike,

  "iss": "https://event.example.com",

Phil

@independentid

On Aug 11, 2016, at 9:32 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                       -- Mike

From: John Bradley [mailto:[email-masked]]
Sent: Thursday, August 11, 2016 12:22 PM
To: Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Marius Scurtescu <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> Ab <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft

John B.

Phil

                                                       -- Mike

Phil

                                                                     -- Mike

Marius

Phil

@independentid

                                                       Thanks again,
                                                       -- Mike

Phil

@independentid

And I’d stop there.

                                                       -- Mike

{

  "aud": "s6BhdRkqt3",

  "iat": 1458668180,

  "exp": 1458668580,

  "events": [

  ],

    "sub": "248289761001”,

    “exp”: <ID token expiry>

  }

}

Phil

@independentid

---

From: Sarah Squire <[email-masked]>
Date: Thu, 11 Aug 2016 11:09:54 -0700

Are we including use cases where the RP is the event issuer?

On Aug 11, 2016 11:02 AM, "Mike Jones" <[email-masked]> wrote:

> You’re aware that forcing “sub” to be a URI is a breaking change for most
> implementations, right?  This is hardly a way to encourage adoption!
>
>
>
> The thing you wrote below that makes me think that you’re thinking about
> the purpose of the ID Events spec differently than me is this: “so that
> all event specs can use it”.  The purpose of the logout event **isn’t**
> for all event specs to use it.  It’s for the logout use case to use it.
> There’s no expectation that events intended for one use case will even be
> comprehensible in other use cases because they won’t understand the
> contents of the event.  We shouldn’t drive any of the design by trying to
> achieve that unachievable goal, since events will **always** contain
> information that’s specific to their use case.
>
>
>
> You’re making complexity arguments, whereas you’re also proposing more
> complex rules than I am (at least as I see it).  Trying to restrict the use
> of “sub” (or any other claims) is unneeded complexity.
>
>
>
> I understand that you see things differently.  I hope you’ll nonetheless
> think about my argument that having fewer rules about claims usage in
> events will make them simpler.  I passionately care about keeping this
> simple, which is why I’m investing my time in this discussion.  If it’s
> simple, it will likely get widely used.
>
>
>
> I’m going to sign out of the discussion for now because my wife is about
> to get out of surgery.  I hope you have a good day.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Phil Hunt [mailto:[email-masked]]
> *Sent:* Thursday, August 11, 2016 12:49 PM
> *Cc:* John Bradley <[email-masked]>; [email-masked]
> Ab <[email-masked]>; [email-masked]; Marius
> Scurtescu <[email-masked]>
> Speaking as editor the format you propose ONLY works if “sub” becomes a
> URI so that all event specs can use it.  Otherwise, OIDC becomes a special
> case which really kills the point of this work. It also makes the
> specification much much more complex. Maybe it is just me, but a complex
> spec generally implies complex implementation too.
>
>
>
> Given that events are signed (or should be), *I will object strongly
> within the OIDF that the event issuer and the token issuer MUST be the same
> or that OIDF adopt a different format*. Yes having iss be the same is a
> nice security convenience, but it imposes the architecture restriction that
> it be the same server.  At scale, delivery of events may become a problem
> for large scale providers if they are also delivering tokens to relying
> parties. The restriction isn’t really justified given the crypto
> alternative — which was the whole point of using JWT in the first place.
>
>
>
> Per Justin’s comment, it seems elegant/trivial that a logout event simply
> has logout at the top level and an ID Token attached (though it might
> convey a lot of unneeded claims).  IMO, the OIDC logout spec should only
> convey the ID Token JTI.  It is going to be rare that you log out all
> devices for a user.  To most users, it means clear SSO within this browser
> only!  One can argue that clearing all devices/sessions is a different
> event entirely. It is an account reset or lock-out action.
>
>
>
> Phil
>
>
>
> @independentid
>
> www.independentid.com
>
> [email-masked]
>
>
>
>
>
>
>
>
>
> See my previous message, John, which was a reply to Phil’s message that
> you also replied to, that contained a logout claims example.  I’m not
> proposing to special-case the Connect Logout message in any way.  The “iss”
> is the event issuer.  The other claims in the message are those defined by
> the event to be included, just like those for any other event.  Yes, the
> logout message doesn’t include a second issuer, a second subject, an ID
> Token as a claim, or anything else complicated like that, because those
> things aren’t needed for the logout use case.
>
>
>
> As I’d written previously, the ID Events spec should define the “events”
> claim, how to use an event name as a claim (when needed), and say that the
> event JWT must be signed by the issuer, and stop there.  Trying to
> micro-manage claims usage within an event will only result in the ID Events
> spec being harder to use.  If we’d tried to similarly micro-manage JWT
> claims usage, JWT would likely not have been the success that it is.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* John Bradley [mailto:[email-masked]]
> *Sent:* Thursday, August 11, 2016 12:22 PM
> *To:* Phil Hunt (IDM) <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; [email-masked]; Marius
> Scurtescu <[email-masked]>; [email-masked] Ab <
> [email-masked]>
> Connect itself doesn’t really have a conflict around issuer the same
> entity sending the logout message is always the one that created the
> id_token that it refers to.
>
>
>
> Using the same format as id_token with the same semantics to identify the
> thing to be terminated makes sense from a purely openID Connect point of
> view.
>
>
>
> Oter messages that have different notions of subject and are issued by
> different parties than the one that controls the subject cause issues when
> you try and fit them into the same format as an ID_Token, I grant you that.
>
>
>
> It was mentioned that we need to differentiate between these events and
> id_tokens.  Mostly we need to do that in cases where the token might be
> presented in the front channel.
>
>
>
> To do that se do have mandatory claims for nonce and c_hash or at_hash as
> well as the addition of events parameter to reduce confusion.   Now I admit
> that some people may still get that wrong,  and the removal of sub from the
> top level would remove any concern.  However Mike has a point that adoption
> may be hurt if we change the semantics too much.
>
>
>
> I don’t see backchannel single logout being used by many social login RP,
> it is a lot of work to maintain server side state.   It is mostly an
> enterprise and large site sort of feature.
>
> That may or may not impact on if it is better to be simple and aligned
> with connect’s id token or more general purpose to fit with other
> enterprise to SaaS features like SCIM events.
>
>
>
> If one spec can use it all must be able to. I believe you previously
> objected to that saying sub must be as how id tokens define them. But that
> isnt unique and requires iss. Now we would have sub at the top with an
> event issuer at the top and a sub issuer in the extension. That seems
> incredibly complex not to mention awkward.
>
>
>
> If we make sub a uri for all then it can work ass iss from id token would
> not be needed. But i can see many objecting to the change in format.
>
>
>
> The simple rule is that if the particular event calls for the “sub” claim
> to be at the top level, then it is.  This is no different from any other
> claim that an event might place at the top level.
>
>
>
> The complexity arises if “sub” is unnecessarily special-cased.  We
> shouldn’t do that, because it limits the applicability of the specification.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Phil Hunt (IDM) [mailto:[email-masked]]
> *Sent:* Thursday, August 11, 2016 9:40 AM
> *Cc:* Marius Scurtescu <[email-masked]>; [email-masked]
> I think using sub at the top level leads to complexity. Eg Can you provide
> a rule for when top level is used or not by an individual spec?  IMO. Top
> level should always be used the same way by all implementers.
>
>
>
> Based on the calls at risc/connect, we discussed that it would be best to
> move all event specifics to the event object area. This way different
> events can have different event addressing (eg sub/iss, uri, jit/iss). When
> iss is needed to uniquely qualify a sub, it can be provided without
> conflicting with the issuer of the event. Similarly jti and iss can be used
> for a revoked token without conflicting with the event jti.
>
>
>
> I plan to post a new draft shortly that will give some examples based on
> feedback from the openid risc/connect discussions.
>
>
>
> No, I’m not saying that “sub” cannot appear at the top level.  I’m saying
> that “sub” will only occur at the top level if the particular event defines
> that “sub” is used in that way for that event.
>
>
>
> There are probably use cases for multiple events per message but I doubt
> there are use cases for multiple **unrelated** events per message.  By
> definition, related events that use top-level claims would need to use them
> in a compatible way.  I don’t see that as being a problem.
>
>
>
>                                                                      --
> Mike
> *From:* Marius Scurtescu [mailto:[email-masked]]
> *Sent:* Tuesday, August 9, 2016 7:15 PM
> *To:* Phil Hunt <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; [email-masked]
> *From:* Phil Hunt [mailto:[email-masked]]
> *From:* Id-event [mailto:[email-masked]] *On Behalf Of *Phil
> Hunt

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 11 Aug 2016 11:27:17 -0700

Sarah,

Good question!

Your use case is really the app initiated logout or logout within the context of a single application. 

If the app initiated front/ backchannel you would be saying log user out of all sso sites for that OP. 

If instead, the app issued the event to the OP, it would be saying the user was logged out of the app. Thus issuer is the app. The OP may or may not take action depending on its policy. 

We need to explore the use case. 

Talking through use cases was part of my reluctance to rushing id token without forming a wg. 
 
Phil

> On Aug 11, 2016, at 11:09 AM, Sarah Squire <[email-masked]> wrote:
>

---

From: Sarah Squire <[email-masked]>
Date: Thu, 11 Aug 2016 11:30:48 -0700

There are also rp-initiated use cases around suspected fraud, parallel
authentication of a second factor, and issuance of a consent receipt.

On Aug 11, 2016 12:27 PM, "Phil Hunt (IDM)" <[email-masked]> wrote:

> If instead, the app issued the event to the OP, it would be saying the
> user was logged out of the app. Thus issuer is the app. The OP may or may
> not take action depending on its policy.
>
>> *Cc:* Mike Jones <[email-masked]>; [email-masked];
>> Marius Scurtescu <[email-masked]>; [email-masked]
>> et Ab <[email-masked]>
>> I think using sub at the top level leads to complexity. Eg Can you
>> provide a rule for when top level is used or not by an individual spec?
>> IMO. Top level should always be used the same way by all implementers.
>>
>>
>>
>> I’m glad to hear that we agree on keeping it as simple and
>> general-purpose as possible and that you agree with my write-up.  I think
>> we then have a good path forward.
>>
>>
>>
>> What I was trying to get at is was that if “http://specs.openid.net/logou
>> t” is used as an event name, that it can also be used as a claim name in
>> the JWT containing information about the event.  (Maybe I’m not using the
>> ·       Include a statement along the lines of “The claims to be
>> included with any particular event are to be defined by the event”
>>
>>
>>
>> And I’d stop there.
>>
>>
>>
>> Taken in the narrower definition, it is important to observe that in an
>> ID Token, “sub” and “iss” go together.  The issuer provides the context for
>> In the above example note that the “event” object can have its own iss
>> and subject (sub or jti) that have meaning within the context of an OpenID
>> OP provider.  The issuer of the event can be different (the top-level) and

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 11 Aug 2016 11:54:33 -0700

Can we step back and look at all the requirements mentioned in this thread
and see if we can simplify them:
1. Multiple events per SET (Security Event Token).
2. SET issuer different from event issuer.
3. Existing Id Token parsers must not confuse a SET for an Id Token.
4. Nested token format.

4 is needed by 1.
4 can fulfill 3, if sub can be present only in nested events.

I don't think 1 is really needed, but with 4 it comes really easy.

A nested format with sub only at event level seems to meet all the
requirements.

Allowing different event specs to define top level claims, like sub, is
very problematic IMO because you can run into incompatible events. Same
with requiring that all events in a single token must refer to the same
sub. This can lead to very complex and buggy publisher implementations.

Marius

On Thu, Aug 11, 2016 at 11:30 AM, Sarah Squire <[email-masked]>
wrote:

>>> You’re aware that forcing “sub” to be a URI is a breaking change for
>>> most implementations, right?  This is hardly a way to encourage adoption!
>>>
>>>
>>>
>>> Per Justin’s comment, it seems elegant/trivial that a logout event
>>> simply has logout at the top level and an ID Token attached (though it
>>> might convey a lot of unneeded claims).  IMO, the OIDC logout spec should
>>> only convey the ID Token JTI.  It is going to be rare that you log out all
>>> Using the same format as id_token with the same semantics to identify
>>> the thing to be terminated makes sense from a purely openID Connect point
>>> of view.
>>>
>>>
>>>
>>> To do that se do have mandatory claims for nonce and c_hash or at_hash
>>> as well as the addition of events parameter to reduce confusion.   Now I
>>> admit that some people may still get that wrong,  and the removal of sub
>>> from the top level would remove any concern.  However Mike has a point that
>>> adoption may be hurt if we change the semantics too much.
>>>
>>>
>>>
>>> I don’t see backchannel single logout being used by many social login
>>> RP, it is a lot of work to maintain server side state.   It is mostly an
>>> If we make sub a uri for all then it can work ass iss from id token
>>> would not be needed. But i can see many objecting to the change in format.
>>>
>>>
>>>
>>> The simple rule is that if the particular event calls for the “sub”
>>> claim to be at the top level, then it is.  This is no different from any
>>> other claim that an event might place at the top level.
>>>
>>>
>>>
>>> Based on the calls at risc/connect, we discussed that it would be best
>>> to move all event specifics to the event object area. This way different
>>> No, I’m not saying that “sub” cannot appear at the top level.  I’m
>>> saying that “sub” will only occur at the top level if the particular event
>>> defines that “sub” is used in that way for that event.
>>>
>>>
>>>
>>> What I was trying to get at is was that if “
>>> http://specs.openid.net/logout” is used as an event name, that it can
>>> also be used as a claim name in the JWT containing information about the
>>> event.  (Maybe I’m not using the correct terminology, hence the unintended
>>> confusion J.)
>>>
>>>
>>>
>>>                                                        Thanks again,
>>>
>>>                                                        -- Mike
>>>
>>>
>>>
>>> Thanks for writing this, Phil.  Unfortunately, the summary below does
>>> not include my feedback, which at the essence, is to keep the ID Events
>>> data structure as simple and general-purpose as possible.  (I strongly
>>> believe that JWT is the success it is because we made JWT as simple and
>>> *  For events that are about a user, the relevant event specification
>>> may include a “sub” attribute within the event’s sub-object and not in the

---

From: Justin Richer <[email-masked]>
Date: Thu, 11 Aug 2016 15:03:31 -0400

+1 to this.

I'd also add that the "pass through" logic I mentioned in the other 
email fits this as well. Basically, if my event *doesn't* have a "sub", 
then I assume it's the same "sub" as the root object. But the lower 
level would always shadow the upper one, in the context of the event 
itself.

This is of course an optimization, but it allows for the kind of 
structures like Mike is talking about without things getting overly 
weird for the general case.

  -- Justin

On 8/11/2016 2:54 PM, Marius Scurtescu via Openid-specs-ab wrote:
> Can we step back and look at all the requirements mentioned in this 
> thread and see if we can simplify them:
> Allowing different event specs to define top level claims, like sub, 
> is very problematic IMO because you can run into incompatible events. 
> Same with requiring that all events in a single token must refer to 
> the same sub. This can lead to very complex and buggy publisher 
> implementations.
>
>
>
> Marius
>
> On Thu, Aug 11, 2016 at 11:30 AM, Sarah Squire 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     There are also rp-initiated use cases around suspected fraud,
>     parallel authentication of a second factor, and issuance of a
>     consent receipt.
>
>
>     On Aug 11, 2016 12:27 PM, "Phil Hunt (IDM)" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Sarah,
>
>         Good question!
>
>         Your use case is really the app initiated logout or logout
>         within the context of a single application.
>
>         If the app initiated front/ backchannel you would be saying
>         log user out of all sso sites for that OP.
>
>         If instead, the app issued the event to the OP, it would be
>         saying the user was logged out of the app. Thus issuer is the
>         app. The OP may or may not take action depending on its policy.
>
>         On Aug 11, 2016, at 11:09 AM, Sarah Squire
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:
>
>>         On Aug 11, 2016 11:02 AM, "Mike Jones"
>>         <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>             You’re aware that forcing “sub” to be a URI is a breaking
>>             change for most implementations, right? This is hardly a
>>             way to encourage adoption!
>>
>>             The thing you wrote below that makes me think that you’re
>>             thinking about the purpose of the ID Events spec
>>             differently than me is this: “so that all event specs can
>>             use it”. The purpose of the logout event **isn’t** for
>>             all event specs to use it.  It’s for the logout use case
>>             to use it.  There’s no expectation that events intended
>>             for one use case will even be comprehensible in other use
>>             cases because they won’t understand the contents of the
>>             event.  We shouldn’t drive any of the design by trying to
>>             achieve that unachievable goal, since events will
>>             **always** contain information that’s specific to their
>>             use case.
>>
>>             You’re making complexity arguments, whereas you’re also
>>             proposing more complex rules than I am (at least as I see
>>             it). Trying to restrict the use of “sub” (or any other
>>             claims) is unneeded complexity.
>>
>>             I understand that you see things differently.  I hope
>>             you’ll nonetheless think about my argument that having
>>             fewer rules about claims usage in events will make them
>>             simpler.  I passionately care about keeping this simple,
>>             which is why I’m investing my time in this discussion. 
>>             If it’s simple, it will likely get widely used.
>>
>>             I’m going to sign out of the discussion for now because
>>             my wife is about to get out of surgery.  I hope you have
>>             a good day.
>>
>>             -- Mike
>>
>>             *From:*Phil Hunt [mailto:[email-masked]
>>             <mailto:[email-masked]>]
>>             *To:* Mike Jones <[email-masked]
>>             <mailto:[email-masked]>>
>>             *Cc:* John Bradley <[email-masked]
>>             <mailto:[email-masked]>>; [email-masked]
>>             <mailto:[email-masked]>.net Ab
>>             <[email-masked]
>>             <mailto:[email-masked]>.net>;
>>             [email-masked] <mailto:[email-masked]>; Marius
>>             Scurtescu <[email-masked]
>>             <mailto:[email-masked]>>
>>             *Subject:* Re: [Id-event] Summarizing recent discussions
>>             on ID-Event token draft
>>
>>             Mike,
>>
>>             Speaking as editor the format you propose ONLY works if
>>             “sub” becomes a URI so that all event specs can use it. 
>>             Otherwise, OIDC becomes a special case which really kills
>>             the point of this work. It also makes the specification
>>             much much more complex. Maybe it is just me, but a
>>             complex spec generally implies complex implementation too.
>>
>>             If you want sub at the top level, that would mean that
>>             the OIDC spec format would have to look like:
>>
>>             {
>>
>>             Given that events are signed (or should be), _I will
>>             object strongly within the OIDF that the event issuer and
>>             the token issuer MUST be the same or that OIDF adopt a
>>             different format_. Yes having iss be the same is a nice
>>             security convenience, but it imposes the architecture
>>             restriction that it be the same server. At scale,
>>             delivery of events may become a problem for large scale
>>             providers if they are also delivering tokens to relying
>>             parties. The restriction isn’t really justified given the
>>             crypto alternative — which was the whole point of using
>>             JWT in the first place.
>>
>>             Per Justin’s comment, it seems elegant/trivial that a
>>             logout event simply has logout at the top level and an ID
>>             Token attached (though it might convey a lot of unneeded
>>             claims).  IMO, the OIDC logout spec should only convey
>>             the ID Token JTI.  It is going to be rare that you log
>>             out all devices for a user.  To most users, it means
>>             clear SSO within this browser only!  One can argue that
>>             clearing all devices/sessions is a different event
>>             entirely. It is an account reset or lock-out action.
>>
>>             Phil
>>
>>             @independentid
>>
>>             www.independentid.com
>>
>>             [email-masked]
>>
>>                 See my previous message, John, which was a reply to
>>                 Phil’s message that you also replied to, that
>>                 contained a logout claims example.  I’m not proposing
>>                 to special-case the Connect Logout message in any
>>                 way. The “iss” is the event issuer.  The other claims
>>                 in the message are those defined by the event to be
>>                 included, just like those for any other event.  Yes,
>>                 the logout message doesn’t include a second issuer, a
>>                 second subject, an ID Token as a claim, or anything
>>                 else complicated like that, because those things
>>                 aren’t needed for the logout use case.
>>
>>                 As I’d written previously, the ID Events spec should
>>                 define the “events” claim, how to use an event name
>>                 as a claim (when needed), and say that the event JWT
>>                 must be signed by the issuer, and stop there.  Trying
>>                 to micro-manage claims usage within an event will
>>                 only result in the ID Events spec being harder to
>>                 use.  If we’d tried to similarly micro-manage JWT
>>                 *From:*John Bradley [mailto:[email-masked]]
>>                 *Sent:*Thursday, August 11, 2016 12:22 PM
>>                 *To:*Phil Hunt (IDM) <[email-masked]>
>>                 *Cc:*Mike Jones <[email-masked]>;
>>                 [email-masked]; Marius Scurtescu
>>                 <[email-masked]>;
>>                 [email-masked] Ab
>>                 <[email-masked]>
>>                 *Subject:*Re: [Id-event] Summarizing recent
>>                 discussions on ID-Event token draft
>>
>>                 Not surprisingly a multipurpose message format will
>>                 not be as optimized as a single purpose one.
>>
>>                 Connect itself doesn’t really have a conflict around
>>                 issuer the same entity sending the logout message is
>>                 always the one that created the id_token that it
>>                 refers to.
>>
>>                 Using the same format as id_token with the same
>>                 semantics to identify the thing to be terminated
>>                 makes sense from a purely openID Connect point of view.
>>
>>                 Oter messages that have different notions of subject
>>                 and are issued by different parties than the one that
>>                 controls the subject cause issues when you try and
>>                 fit them into the same format as an ID_Token, I grant
>>                 you that.
>>
>>                 It was mentioned that we need to differentiate
>>                 between these events and id_tokens. Mostly we need to
>>                 do that in cases where the token might be presented
>>                 in the front channel.
>>
>>                 To do that se do have mandatory claims for nonce and
>>                 c_hash or at_hash as well as the addition of events
>>                 parameter to reduce confusion. Now I admit that some
>>                 people may still get that wrong,  and the removal of
>>                 sub from the top level would remove any concern.
>>                 However Mike has a point that adoption may be hurt if
>>                 we change the semantics too much.
>>
>>                 I don’t see backchannel single logout being used by
>>                 many social login RP, it is a lot of work to maintain
>>                 server side state. It is mostly an enterprise and
>>                 large site sort of feature.
>>
>>                 That may or may not impact on if it is better to be
>>                 simple and aligned with connect’s id token or more
>>                 general purpose to fit with other enterprise to SaaS
>>                 features like SCIM events.
>>
>>                 The compromise of special casing Connect SLO and
>>                 bodging the formats together is probably the worst
>>                 option.
>>
>>                 John B.
>>
>>                     How do you resolve conflicts on iss then?  The
>>                     top level has to be the issuer of the event as
>>                     the issuer signs.
>>
>>                     If one spec can use it all must be able to. I
>>                     believe you previously objected to that saying
>>                     sub must be as how id tokens define them. But
>>                     that isnt unique and requires iss. Now we would
>>                     have sub at the top with an event issuer at the
>>                     top and a sub issuer in the extension. That seems
>>                     If we make sub a uri for all then it can work ass
>>                     iss from id token would not be needed. But i can
>>                     see many objecting to the change in format.
>>
>>                         The simple rule is that if the particular
>>                         event calls for the “sub” claim to be at the
>>                         top level, then it is. This is no different
>>                         from any other claim that an event might
>>                         place at the top level.
>>
>>                         The complexity arises if “sub” is
>>                         unnecessarily special-cased.  We shouldn’t do
>>                         that, because it limits the applicability of
>>                         the specification.
>>
>>                         -- Mike
>>
>>                         *From:*Phil Hunt (IDM)
>>                         [mailto:[email-masked]]
>>                         *Sent:*Thursday, August 11, 2016 9:40 AM
>>                         *To:*Mike Jones <[email-masked]>
>>                         *Cc:*Marius Scurtescu
>>                         <[email-masked]>;[email-masked]
>>                         *Subject:*Re: [Id-event] Summarizing recent
>>                         discussions on ID-Event token draft
>>
>>                         I think using sub at the top level leads to
>>                         complexity. Eg Can you provide a rule for
>>                         when top level is used or not by an
>>                         individual spec?  IMO. Top level should
>>                         always be used the same way by all implementers.
>>
>>                         Based on the calls at risc/connect, we
>>                         discussed that it would be best to move all
>>                         event specifics to the event object area.
>>                         This way different events can have different
>>                         event addressing (eg sub/iss, uri, jit/iss).
>>                         When iss is needed to uniquely qualify a sub,
>>                         it can be provided without conflicting with
>>                         the issuer of the event. Similarly jti and
>>                         iss can be used for a revoked token without
>>                         conflicting with the event jti.
>>
>>                         I plan to post a new draft shortly that will
>>                         give some examples based on feedback from the
>>                         openid risc/connect discussions.
>>
>>                             No, I’m not saying that “sub” cannot
>>                             appear at the top level.  I’m saying that
>>                             “sub” will only occur at the top level if
>>                             the particular event defines that “sub”
>>                             is used in that way for that event.
>>
>>                             There are probably use cases for multiple
>>                             events per message but I doubt there are
>>                             use cases for multiple **unrelated**
>>                             events per message.  By definition,
>>                             related events that use top-level claims
>>                             would need to use them in a compatible
>>                             way.  I don’t see that as being a problem.
>>
>>                             *From:*Marius Scurtescu
>>                             [mailto:[email-masked]]
>>                             *Sent:*Tuesday, August 9, 2016 7:15 PM
>>                             *To:*Phil Hunt <[email-masked]>
>>                             *Cc:*Mike Jones
>>                             <[email-masked]>;[email-masked]
>>                             *Subject:*Re: [Id-event] Summarizing
>>                             recent discussions on ID-Event token draft
>>
>>                             Mike, are you suggesting that a sub claim
>>                             can only show up at the event level and
>>                             not at the top level:
>>
>>                                 claim is that “Like all other claims
>>                                 other than ‘events’ and ‘iss’,
>>                                 whether the ‘sub’ claim is to be
>>                                 included with an event is entirely
>>                                 event-specific.
>>
>>                                     On Aug 9, 2016, at 12:12 PM, Mike
>>                                     Jones
>>                                     <[email-masked]> wrote:
>>
>>                                     general-purpose as possible and
>>                                     that you agree with my write-up. 
>>                                     I think we then have a good path
>>                                     forward.
>>
>>                                     I’m not sure what you mean by
>>                                     “I’m not sure that we need a
>>                                     “name”. What is your intention
>>                                     there.” The only place I used the
>>                                     word “name” was in my statement
>>                                     “Define that an event name can be
>>                                     used as a top-level claim”.  What
>>                                     I was trying to get at is was
>>                                     that if
>>                                     “http://specs.openid.net/logout”
>>                                     is used as an event name, that it
>>                                     can also be used as a claim name
>>                                     in the JWT containing information
>>                                     about the event.  (Maybe I’m not
>>                                     using the correct terminology,
>>                                     hence the unintended confusionJ.)
>>
>>                                     Thanks again,
>>
>>                                     -- Mike
>>
>>                                     *From:*Phil Hunt
>>                                     [mailto:[email-masked]]
>>                                     *Sent:*Tuesday, August 9, 2016
>>                                     12:07 PM
>>                                     *To:*Mike Jones
>>                                     <[email-masked]>
>>                                     *Cc:[email-masked]
>>                                     *Subject:*Re: [Id-event]
>>                                     Summarizing recent discussions on
>>                                     ID-Event token draft
>>
>>                                     I didn’t cover this as I didn’t
>>                                     want to confuse people with too
>>                                     many things.
>>
>>                                         On Aug 9, 2016, at 11:54 AM,
>>                                         Mike Jones
>>                                         <[email-masked]>
>>                                         wrote:
>>
>>                                         Thanks for writing this,
>>                                         Phil. Unfortunately, the
>>                                         summary below does not
>>                                         include my feedback, which at
>>                                         the essence, is to keep the
>>                                         ID Events data structure as
>>                                         simple and general-purpose as
>>                                         possible.  (I strongly
>>                                         believe that JWT is the
>>                                         success it is because we made
>>                                         JWT as simple and
>>                                         general-purpose as possible,
>>                                         and we should follow this
>>                                         successful example and do the
>>                                         same here.)
>>
>>                                         I believe that the ID Events
>>                                         spec needs to include these
>>                                         things, and these things only:
>>
>>                                         ·Define of the “events” claim
>>
>>                                         ·Define that an event name
>>                                         can be used as a top-level claim
>>
>>                                         ·Require that “iss” be
>>                                         included and that the JWT be
>>                                         signed by the issuer
>>
>>                                         ·Include a statement along
>>                                         the lines of “The claims to
>>                                         be included with any
>>                                         particular event are to be
>>                                         defined by the event”
>>
>>                                         And I’d stop there.
>>
>>                                         It should be entirely up to
>>                                         applications to say what
>>                                         claims are included with
>>                                         events they define and what
>>                                         their format and meanings
>>                                         are. Then the ID Events spec
>>                                         will be as general-purpose as
>>                                         possible, with it being
>>                                         natural for it to be used in
>>                                         essentially all JSON Event
>>                                         contexts.
>>
>>                                         As soon as we start putting
>>                                         restrictions on the use of
>>                                         particular claims by events,
>>                                         we’re making the ID Events
>>                                         spec less general-purpose and
>>                                         less natural to use.  In
>>                                         particular, the only thing
>>                                         that the spec should say
>>                                         about the “sub” claim is that
>>                                         “Like all other claims other
>>                                         than ‘events’ and ‘iss’,
>>                                         whether the ‘sub’ claim is to
>>                                         be included with an event is
>>                                         entirely event-specific. The
>>                                         claims to be included with
>>                                         any particular event are
>>                                         explicitly outside the scope
>>                                         of this specification.”
>>
>>                                         -- Mike
>>
>>                                         *From:*Id-event
>>                                         [mailto:[email-masked]]*On
>>                                         Behalf Of*Phil Hunt
>>                                         *Sent:*Tuesday, August 9,
>>                                         2016 10:19 AM
>>                                         *To:[email-masked]
>>                                         *Subject:*[Id-event]
>>                                         Summarizing recent
>>                                         discussions on ID-Event token
>>                                         draft
>>
>>                                         I thought I would update the
>>                                         list on some discussions that
>>                                         have been happening over in
>>                                         the OpenID Connect and RISC
>>                                         working groups conference calls.
>>
>>                                         These discussions have been
>>                                         about the core spec and the
>>                                         role of “top-level”
>>                                         attributes vs. event
>>                                         “extension” attributes.
>>
>>                                         See:https://tools.ietf.org/html/draft-hunt-idevent-token-01
>>
>>                                         In particular should “sub” be
>>                                         used in the top level to
>>                                         “point” to the subject (in
>>                                         the broader english sense) of
>>                                         the event, or should it be
>>                                         constrained to the SAML/ID
>>                                         Token definition which is the
>>                                         authenticated user.
>>
>>                                         Taken in the narrower
>>                                         definition, it is important
>>                                         to observe that in an ID
>>                                         Token, “sub” and “iss” go
>>                                         together.  The issuer
>>                                         provides the context for the
>>                                         authenticated subject
>>                                         identifier. The problem with
>>                                         events, is that it might not
>>                                         be the AS (or OP) which is
>>                                         issuing the event.
>>
>>                                         To summarize a fair amount of
>>                                         discussion, the feeling seems
>>                                         to be the following:
>>
>>                                         *  The Event Token top level
>>                                         attributes should be fairly
>>                                         limited and not include the
>>                                         sub attribute.
>>
>>                                         *  For events that are about
>>                                         a user, the relevant event
>>                                         specification may include a
>>                                         “sub” attribute within the
>>                                         event’s sub-object and not in
>>                                         the top-level. Further that
>>                                         sub-object can also include
>>                                         the issuer of the user.
>>
>>                                         * The top-level “iss” shall
>>                                         mean the issuer of the event
>>                                         where the state change occurred.
>>
>>                                         *  “sub” should not be
>>                                         present in the top level
>>                                         structure. Also, “events”
>>                                         must also be present.
>>
>>                                         In the above example note
>>                                         that the “event” object can
>>                                         have its own iss and subject
>>                                         (sub or jti) that have
>>                                         meaning within the context of
>>                                         an OpenID OP provider.  The
>>                                         issuer of the event can be
>>                                         different (the top-level) and
>>                                         represents the entity that
>>                                         signs the event (if it is
>>                                         signed).
>>
>>                                         The top-level attributes
>>                                         identify an individual event
>>                                         and are used to validate the
>>                                         event (signing etc).  Where
>>                                         as the nested object contains
>>                                         all of the data about the
>>                                         event and is defined by the
>>                                         profiling specification (e.g.
>>                                         a possible OpenID Logout
>>                                         Event spec).  In this case,
>>                                         in OpenID, logging out
>>                                         usually translates into
>>                                         revoking an ID Token. Thus
>>                                         the “jti” for the ID token
>>                                         (08a5019c...843ea02) is
>>                                         included in the Logout object.
>>
>>                                         Side note.  Regarding
>>                                         “logout”, it might be useful
>>                                         to include the expiry of the
>>                                         ID Token in case the
>>                                         subscriber has not yet
>>                                         received an ID Token. This
>>                                         would let the subscriber know
>>                                         how long it needs to keep the
>>                                         revocation information for.
>>                                         IOW…after the the ID Token is
>>                                         expired, the subscriber would
>>                                         no longer need to track the
>>                                         revocation state.
>>
>>                                         It is also good to observe
>>                                         that the “aud” at the top
>>                                         level describes the
>>                                         subscriber of the event. 
>>                                         This may also be different
>>                                         then the original audience of
>>                                         the ID Token.
>>
>>                                         So to conclude. By making
>>                                         top-level attributes strictly
>>                                         about the events own
>>                                         validation, and nested
>>                                         objects about the event, we
>>                                         avoid collisions in
>>                                         definitions such as the
>>                                         issuer of the event, vs. the
>>                                         original issuer of a security
>>                                         assertion.
>>
>>                                         I hope I’ve gotten everyone’s
>>                                         feedback correct here. Lets
>>                                         continue to discuss. I will
>>                                         revise the draft to follow
>>                                         the groups thinking here.
>>
>>                                         Phil
>>
>>                                         @independentid
>>
>>                                         www.independentid.com
>>
>>                                         [email-masked]
>>
>>                                     [email-masked]://www.ietf.org/mailman/listinfo/id-event
>>
>>                             Id-event mailing list [email-masked]
>>                     Id-event mailing list [email-masked]
>>                 Id-event mailing list [email-masked]
>>             _______________________________________________ Id-event
>>             mailing list [email-masked] <mailto:[email-masked]>
> Openid-specs-ab mailing list
> [email-masked]
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 11 Aug 2016 12:19:13 -0700

+1

Great discussion folks. 

I hope to put in an example of consent that Sarah mentioned too. I think it really adds to the discussions. 

I will publish the next draft knowing that we are not there yet. 

But as long as we keep discussing that is a good thing!

Phil

> On Aug 11, 2016, at 11:54 AM, Marius Scurtescu <[email-masked]> wrote:
> 
> Can we step back and look at all the requirements mentioned in this thread and see if we can simplify them:
> A nested format with sub only at event level seems to meet all the requirements.
> 
> Allowing different event specs to define top level claims, like sub, is very problematic IMO because you can run into incompatible events. Same with requiring that all events in a single token must refer to the same sub. This can lead to very complex and buggy publisher implementations.
> 
> 
> 
> Marius
> 
>> On Thu, Aug 11, 2016 at 11:30 AM, Sarah Squire <[email-masked]> wrote:
>> There are also rp-initiated use cases around suspected fraud, parallel authentication of a second factor, and issuance of a consent receipt.
>> 
>>