Addition of Event data field inside events
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"
}
}
}
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.
I can start on this if you would like
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
to accomplish this, i believe we'd need to add event_data to specific schemas? or has there been another way discussed?
@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"
}
}
}
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.
This PR was closed in favor of #250 - Decided at 4/15 meeting