Open scvenema opened 1 year ago
From the discussion today, here is the reformatted version of Steve's proposed SET:
{
"iss": "https://idp.example.com/",
"jti": "756E69717565206964656E746966696572",
"iat": 1520364019,
"aud": "636C69656E745F6964",
"sub_id": {
"format": "aliases",
"identifiers": [
{
"format": "user",
"user_id": "foo"
},
{
"format": "device",
"device_id": "bar"
}
],
},
"events": {
"https://schemas.openid.net/secevent/caep/event-type/session-revoked": {
"initiating_entity": "policy",
"reason_admin": "Policy Violation: C076E82F",
"reason_user": "Landspeed violation.",
"event_timestamp": 1600975810
}
}
}
@FragLegs , what is the status of this issue?
I think that once we realized that the Aliases format does not carry the same semantic information as the Complex format, the issue was dropped. That is, you could put all of the Simple subjects that make up a Complex subject into an Aliases format instead, but you would no longer know whether each Simple subject referred to a user, a group, a tenant, etc.
What about @independentid 's original comment that sparked this thread? Should we consider changing complex
format to ssf-complex
to make it less likely to conflict with something else?
A recent comment by Phil Hunt a few days ago in PR #82
...caused to wonder why we are using this "Simple" and "Complex construct when the
aliases
subject ID type is already defined in draft-ietf-secevent-subject-identifiers-18 §3.2.8 and seems to fit our use case?If we used
aliases
, then the Figure 6 example in the current draft of the Framework spec would instead look like:I thought I brought this up on the 2022-06-20 call, but it somehow morphed into the "simple"/"complex" approach and I can't remember why. I recall @timcappalli mentioning some issue about nesting the array format being more difficult to process. I see that the
aliases
spec specifically precludes nesting; is nesting needed for some use case? From a (de)serializing perspective, it seems like we already need to deal with thisaliases
type to conform with the draft IETF spec linked above so it should make things easier rather than more difficult for implementation.Other observations:
I'm happy to do edits on the draft and open a PR if there is any consensus on these questions.