Subject: [Id-event] Proposed changes to the event spec

From: William Denniss <[email-masked]>
Date: Fri, 8 Apr 2016 11:59:45 -0300

Yesterday, Mike, John, Nat and I workshopped the draft OpenID Back-Channel
Logout Token format to see what it would look like formatted as an id-event.

We used a URL for the event type (to avoid registering a URN, and also
because URLs can be self-documenting which is nice, and we've used this
structure before in OpenID).  The outcome was pretty good, take a look at
the post to the OpenID Connect WG here:
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006016.html

Here's the example logout token we came up with:

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

I've made a few proposed changes to the id-events spec, including
simplifying the claim name from "eventURIs" to just "events", and added
this example to the spec, as well as some minor editorial changes.

Please review my changes:
https://github.com/independentid/Identity-Events/pull/1

William

---

From: Justin Richer <[email-masked]>
Date: Fri, 8 Apr 2016 11:18:45 -0400

I know I missed the discussion the other day, but I have a question about the data structure:

What’s the purpose of having the “events” array below if the values of said array are going to be keys in the overlying object? It seems unnecessary duplication of information.

 — Justin

> On Apr 8, 2016, at 10:59 AM, William Denniss <[email-masked]> wrote:
> 
> Yesterday, Mike, John, Nat and I workshopped the draft OpenID Back-Channel Logout Token format to see what it would look like formatted as an id-event.
> 
> We used a URL for the event type (to avoid registering a URN, and also because URLs can be self-documenting which is nice, and we've used this structure before in OpenID).  The outcome was pretty good, take a look at the post to the OpenID Connect WG here: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006016.html <http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006016.html>
> 
>       "iss": "https://server.example.com <https://server.example.com/>",
>       "aud": "s6BhdRkqt3",
>           "https://specs.openid.net/logout <https://specs.openid.net/logout>"
>       ],
>       "https://specs.openid.net/logout <https://specs.openid.net/logout>": {
> I've made a few proposed changes to the id-events spec, including simplifying the claim name from "eventURIs" to just "events", and added this example to the spec, as well as some minor editorial changes.
> 
> https://github.com/independentid/Identity-Events/pull/1 <https://github.com/independentid/Identity-Events/pull/1>
> 
> William
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Leif Johansson <[email-masked]>
Date: Fri, 8 Apr 2016 17:19:55 +0200

On 2016-04-08 17:18, Justin Richer wrote:
> What’s the purpose of having the “events” array below if the values of
> said array are going to be keys in the overlying object? It seems
> unnecessary duplication of information.

I guess cause it allows you to identity what part of the structure you
have to care about if you treat this as an "event"

> 
>  — Justin
> 
>> On Apr 8, 2016, at 10:59 AM, William Denniss <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Yesterday, Mike, John, Nat and I workshopped the draft
>> OpenID Back-Channel Logout Token format to see what it would look like
>> formatted as an id-event.
>>
>> because URLs can be self-documenting which is nice, and we've used
>> this structure before in OpenID).  The outcome was pretty good, take a
>> look at the post to the OpenID Connect WG
>> here: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006016.html
>>
>> simplifying the claim name from "eventURIs" to just "events", and
>> added this example to the spec, as well as some minor editorial changes.
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 8 Apr 2016 12:32:19 -0300

Justin,

Some events will be self defining…especially if all that is needed is the “sub” as the target of the event.

E.g. sub could be a token id you want to revoke...

 {
     "iss": "https://server.example.com <https://server.example.com/> <https://server.example.com/ <https://server.example.com/>>",
     "aud": "s6BhdRkqt3",
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "sub": "248289761001",
     "iat": 1458668180,
     "exp": 1458668580,
     "events": [
         "https://tools.ietf.org/html/rfc6749#revoke"
     ]
 }

Phil

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

> On Apr 8, 2016, at 12:19 PM, Leif Johansson <[email-masked]> wrote:
> 
>>> On Apr 8, 2016, at 10:59 AM, William Denniss <[email-masked] <mailto:[email-masked]>
>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
>>> here: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006016.html <http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006016.html>
>>> 
>>>      "iss": "https://server.example.com <https://server.example.com/> <https://server.example.com/ <https://server.example.com/>>",
>>>      "aud": "s6BhdRkqt3",
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>> 
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>> 
> 
> 
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>

---

From: William Denniss <[email-masked]>
Date: Fri, 8 Apr 2016 12:38:14 -0300

The "events" claim tells you that it's an event JWT without you needing to
scan for all events you support (and it means you'll also be able to know
if it's an event that perhaps you don't support). Otherwise they could be
confused with collision-resistant public claims
<https://tools.ietf.org/html/rfc7519#section-4.2>.

Also, it's possible that the event is so simple it actually doesn't even
need its own attribute dictionary. Thought of that after I sent the pull
request, will make a new revision shortly. In this simple case, declaring
the event's type is enough.

E.g.:

{

NB. we expect "sid" (session id) to be a standard JWT claim in Connect
going forward as it's needed by a few different specs in progress, hence
why it wouldn't need to be an event-specific attribute.

On Fri, Apr 8, 2016 at 12:20 PM Leif Johansson <[email-masked]> wrote:

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

---

From: Justin Richer <[email-masked]>
Date: Fri, 8 Apr 2016 12:09:55 -0400

Then why not just have:

{
  "iss": "https://server.example.com",
  "aud": "s6BhdRkqt3",
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "sub": "248289761001",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": {
    "https://specs.openid.net/logout”: <https://specs.openid.net/logout%E2%80%9D:> "08a5019c-17e1-4977-8f42-65a12843ea02”
  }
}

 — Justin

> On Apr 8, 2016, at 11:38 AM, William Denniss <[email-masked]> wrote:
> 
> The "events" claim tells you that it's an event JWT without you needing to scan for all events you support (and it means you'll also be able to know if it's an event that perhaps you don't support). Otherwise they could be confused with collision-resistant public claims <https://tools.ietf.org/html/rfc7519#section-4.2>.
> 
> Also, it's possible that the event is so simple it actually doesn't even need its own attribute dictionary.  Thought of that after I sent the pull request, will make a new revision shortly. In this simple case, declaring the event's type is enough.
> 
> E.g.:
> 
> {
> NB. we expect "sid" (session id) to be a standard JWT claim in Connect going forward as it's needed by a few different specs in progress, hence why it wouldn't need to be an event-specific attribute.
> 
> 
> On Fri, Apr 8, 2016 at 12:20 PM Leif Johansson <[email-masked] <mailto:[email-masked]>> wrote:

---

From: William Denniss <[email-masked]>
Date: Fri, 08 Apr 2016 16:14:26 +0000

In this example, the event doesn't need to convey any data beyond the type,
as it uses only standard claims (we plan to standardize "sid" for
session-id, independent of back-channel logout).
On Fri, Apr 8, 2016 at 1:09 PM Justin Richer <[email-masked]> wrote:

>     "https://specs.openid.net/logout”:
>  "08a5019c-17e1-4977-8f42-65a12843ea02”
>   }
> }
>
>
>  — Justin
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 8 Apr 2016 12:19:04 -0400

I guess part of what I’m questioning is whether the ID Events really need to have all the JWT structures to begin with. People seem to be allergic to using JWS to wrap any structure that’s not a JWT, but if we took a step back from the assumption that we should be using JWT claims we might find a better representation here. 

These aren’t really tokens or assertions. They’re more log entries designed to be carried in a protected way across the network.

 — Justin

> On Apr 8, 2016, at 12:14 PM, William Denniss <[email-masked]> wrote:
> 
> In this example, the event doesn't need to convey any data beyond the type, as it uses only standard claims (we plan to standardize "sid" for session-id, independent of back-channel logout).
> On Fri, Apr 8, 2016 at 1:09 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> Then why not just have:
> 
> {
>> On Apr 8, 2016, at 11:38 AM, William Denniss <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 8 Apr 2016 13:25:44 -0300

The dictionary model certainly makes it distinguished from a security assertion.

Phil

@independentid

> On Apr 8, 2016, at 1:19 PM, Justin Richer <[email-masked]> wrote:
> 
>> On Apr 8, 2016, at 12:14 PM, William Denniss <[email-masked] <mailto:[email-masked]>> wrote:
>>