Security Events 101 – Distributed Architecture Evolution

Security Event Token 101

Tuesday 5A

Convener: Marius Scurtescu

Notes-taker(s): Marius Scurtescu

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Presentation link:

https://github.com/independentid/Identity-Events/raw/master/SecurityEvents101-IIW23.pdf

• clarification if SET only describes events or also deals with distribution
  • both, session for distribution tomorrow
• is JWT signature really optional? probably not
• query interface use case, around registration, pub/sub does not work
• account suspended event should also have a corresponding account restored event
• event order can be mittigated by adding event time stamps
  • VM time is not reliable
  • sequence numbers are not feasible with move towards decentralization
  • pointing to previous evnets when current one is issued is also problematic, leads to graph of events
• why numtiple identifier for user in password reset example
  • sub is in name space of issuer, other identifier nested in event sub-message
• is batching supported?
  • some changes could generate a massive ammount of evnets, this is when batching would be useful
  • batching at event level vs transport level
• logout example, nested iss
  • real world use cases
  • care with session identifiers, may not be useful
  • multiple devices use case
• why not nest event detaisl in the "events" attribute?
  • events could be an object, keys are event URIs, values are event sub-objects
  • events could be an array, each element is an event sub-object
  • current solution popular and inspired by SCIM
• what prevents these SETs from being used for authentication as Id Tokens?

Syntax change proposal from Justin Richer:

In the session at IIW yesterday, there was a discussion on the event syntax in the current proposed draft. A few of us (myself included) questioned the current structure which is something like this:

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

To get the above information, I need to walk through the values in the “events” array and then look for those values as members of the root JSON object to see if they have data. Instead, I’d like to raise an alternative way to codify the same event in a way that I believe will be more easily understandable by implementors and easier to parse by both humans and code. Namely, skip the array definition and build out the event above like so:

  {
    "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
    "events”: {
       "urn:ietf:params:scim:event:passwordReset":{
         "id":"44f6142df96bd6ab61e7521d9"
       },
       "https://example.com/scim/event/passwordResetExt":{
          "resetAttempts":5
       }
    },
    "iat": 1458496025,
    "iss": "https://scim.example.com",
    "aud":[
      "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
      "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
    ],
    "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9"
  }

With this syntax, I need to loop through the keys of the “events” object and don’t need to reference anything else in the root object. This is *much* easier to code, and it enforces that each event key appear only once. Plus it keeps event information out of the root of the JWT, which has been shown (with JAR, dynamic registration’s software statements, and a couple others) to be problematic at times.

An argument for the current syntax is that it can handle event types that don’t have any additional payload. While I don’t think I’ve seen a concrete example of one yet (I might just be missing it), we can still handle that in this syntax in a number of ways. First, we could just use an empty object when there are no arguments.

    "events”: {
       "urn:ietf:params:scim:event:passwordReset":{}
    },

Second, we could just use “null”, which OpenID Connect uses in the “claims” object:

    "events”: {
       "urn:ietf:params:scim:event:passwordReset”:null
    },

Or a stand-in value like the “true” boolean:

    "events”: {
       "urn:ietf:params:scim:event:passwordReset”:true
    },

I prefer the first as it doesn’t change the expected object model for all claims, and it also takes fewer characters on the wire (not by much, so that’s not a driving factor, but with a lot of these saving a couple bytes won’t hurt).

— Justin

Full thread at: https://mailarchive.ietf.org/arch/search/?email_list=id-event&gbt=1&index=EZJO2uiOOF0MZgbLBzkUWuNITkE