sharedsignals icon indicating copy to clipboard operation
sharedsignals copied to clipboard

Addition of Event data field inside events

Open iamseanodentity opened this issue 1 year ago • 5 comments

The intent is to be able to offer guidelines for all events in order to allow transmitters to provide more metadata that can be specific to the event and or action(s) in the event.

example:

  "events": {
    "https://schemas.openid.net/secevent/caep/event-type/session-revoked": {
      "event_timestamp": 1615304991643,
      "event_data": {
        "something":"foo",
        "blah":"bar",
        "blah2":"example2"
      }
    }
  }

iamseanodentity avatar Nov 07 '24 20:11 iamseanodentity

This can be a change to the SSF spec, where we add recommended language about any additional data that needs to be sent in an event SHOULD be sent using the "event_data" field.

tulshi avatar Nov 07 '24 21:11 tulshi

I can start on this if you would like

iamseanodentity avatar Nov 08 '24 17:11 iamseanodentity

How would we handle the bloating of the event? Should there be a recommendation on the size? Restrictions on keys to avoid conflicts with optional/mandatory event fields etc

appsdesh avatar Mar 18 '25 16:03 appsdesh

to accomplish this, i believe we'd need to add event_data to specific schemas? or has there been another way discussed?

jischr avatar Mar 20 '25 14:03 jischr

@jischr I think that's correct. We should update the CAEP and RISC specs, not the SSF spec.

If we wanted to limit this change to the SSF spec, we could potentially create a field that lives at the same level as events to hold this information, but that feels a bit gross to me. It would look like this

{
  "iss": "https://idp.example.com/",
  "jti": "756E69717565206964656E746966696572",
  "iat": 1520364019,
  "txn": 8675309,
  "aud": "636C69656E745F6964",
  "sub_id": {
    "format": "email",
    "email": "[email protected]"
  },
  "events": {
    "https://schemas.openid.net/secevent/caep/event-type/token-claims-change": {
      "claims": {
        "token": "some-token-value"
      }
    }
  },
  "event_data": {
    "https://schemas.openid.net/secevent/caep/event-type/token-claims-change": {
        "something":"foo",
        "blah":"bar",
        "blah2":"example2"
    }
  }
}

FragLegs avatar Mar 25 '25 13:03 FragLegs

I'd like to understand why this should be in the CAEP / RISC specs versus being in the SSF spec. I'm thinking the "event_data" field is something we will need for any event, not just for those defined by CAEP and RISC. Also, I'd prefer to put the event_data field inside the "events" field, in case we move to a structure in the future where there are more than one events in the "events" claim.

tulshi avatar Apr 11 '25 00:04 tulshi

This PR was closed in favor of #250 - Decided at 4/15 meeting

jischr avatar Apr 22 '25 17:04 jischr