Should subject identifier be pulled out of the event definitions? about sharedsignals HOT 9 CLOSED

On the April 5 call we were discussing what it means to be a general SSF server and whether a server should be capable of serving multiple classes of events (e.g. CAEP, RISC, SCIM).

It occurs to me that other then the event type, the subject of an event is also one of the most critical information items an event handler needs in order to determine whether a stream needs an event or not.

Having identity/subject information buried inside of events under different attributes as it would make general inter-operability and utility impossible due to the event specific knowledge an SSF framework would need.

For this reason, I would like to see the sub_id claim used at the top level to enable stream filtering without the need to parse event payloads.

from sharedsignals.

In both the RISC and CAEP specs, events have subjects in the payload. Such as:
{ "iss": "https://idp.example.com/", "jti": "756E69717565206964656E746966696572", "iat": 1508184845, "aud": "636C69656E745F6964", "events": { "https://schemas.openid.net/secevent/risc/event-type/\ account-credential-change-required": { "subject": { "format": "iss_sub", "iss": "https://idp.example.com/", "sub": "7375626A656374", } } } }

A better approach would be:
{ "iss": "https://idp.example.com/", "jti": "756E69717565206964656E746966696572", "iat": 1508184845, "aud": "636C69656E745F6964", "sub_id": { "format": "iss_sub", "iss": "https://idp.example.com/", "sub": "7375626A656374", } "events": { "https://schemas.openid.net/secevent/risc/event-type/\ account-credential-change-required": { } } }

This format keeps the sub_id in the top level as a registered JWT claim. It allows an SSF server to determine which streams should receive the event. The SSF server should only have to understand registered claims, where as the receiver needs to understand the events, their meaning and any payload specific attributes/claims. This is also useful in support of the SSF AddSubject/RemoveSubject stream management function (as it would support easier filtering).

SCIM events will be using this (format="scim") because it is possible that compound events will be included. A compound event could be something like a password change, where one event is the data change (modify) and the other is a high level risc style event. Placing the sub_id in the top-level forces the meaning that each event is about the same subject.

from sharedsignals.

This format keeps the sub_id in the top level as a registered JWT claim

Looking at rfc7519 I can't find sub_id to be a registered claim, could you please clarify this point?

If the main concern is processing efficiency, then can adding stream_id at the top level solve the problem for you? The receiver server could do routing based on the stream_id to the specific streams

from sharedsignals.

from sharedsignals.

@appsdesh you can find sub_id defined in the Subject Identifiers for Security Event Tokens spec, which SSF makes heavy use of.

from sharedsignals.

Copying in relevant comments from issue #60

#60 (comment) from @scvenema

Building on Shayne's concerns, §11.1.8.1 of the current framework draft seems to imply there is some unfinished business in harmonizing this SSF framework spec with the Subject Identifiers for SETs - draft 17 spec? I'm referring to the phrase, "The Shared Signals Framework is asking for further restrictions"...

We seem to have three different subject-like fields in play here:

"sub" as defined in RFC 7519 §4.1.2
"sub_id" as defined in §4.1 of the Subject Identifiers for SETs spec (draft 17)

"subject" as defined in our SSF Frameworks draft spec, which is part of an event JWT claim, and requires the exclusion of "sub" (and "sub_id") usages for SETs
Plus a new term defined in the framework spec: "Subject Principal", which seems to overlap with the term "subject" used in the secevent specs.
It all seems a bit muddy to an SSF noob like me. I understand that "sub_id" is needed because the "sub" claim's value has type StringOrURI, while "sub_id" claim's value is a JSON object instead. I expect that there is some history behind all of this that I'm not aware of. But, at a minimum, I think we could add some additional non-normative explanatory text somewhere in the framework spec that clarifies these distinctions. I'd be happy to draft some text, but I think it might be useful to first discuss this on an upcoming WG call.

I'm happy to open this as a separate issue if desired.

from sharedsignals.

#60 (comment) from @independentid

Just an FYI item. The sub claim is problematic in the context of SET tokens for 2 major reasons:1 . Sub in a JWT was always defined in connection with an issuer. However, in OpenId if a client issues an event its “iss” value is different. This is why the subject identifier draft came about and why there is a format for this. 2. There is a security worry (not sure how legit it is) that a set might be confused as authorization. This is why rfc8417 recommends against using the “sub” claim. I would recommend implementers NOT use “sub” per 8417. PhilOn Jun 24, 2023, at 3:44 PM, Steve Venema @.***> wrote:
Building on Shayne's concerns, §11.1.8.1 of the current framework draft seems to imply there is some unfinished business in harmonizing this SSF framework spec with the Subject Identifiers for SETs - draft 17 spec? I'm referring to the phrase, "The Shared Signals Framework is asking for further restrictions"...
We seem to have three different subject-like fields in play here:

"sub" as defined in RFC 7519 §4.1.2
"sub_id" as defined in §4.1 of the Subject Identifiers for SETs spec (draft 17)
"subject" as defined in our SSF Frameworks draft spec, which is part of an event JWT claim, and requires the exclusion of "sub" (and "sub_id") usages for SETs
Plus a new term defined in the framework spec: "Subject Principal", which seems to overlap with the term "subject" used in the secevent specs.

It all seems a bit muddy to an SSF noob like me. I understand that "sub_id" is needed because the "sub" claim's value has type StringOrURI, while "sub_id" claim's value is a JSON object instead. I expect that there is some history behind all of this that I'm not aware of. But, at a minimum, I think we could add some additional non-normative explanatory text somewhere in the framework spec that clarifies these distinctions. I'd be happy to draft some text, but I think it might be useful to first discuss this on an upcoming WG call.
I'm happy to open this as a separate issue if desired.

from sharedsignals.

I want to call out one point of clarification about what @scvenema said

SSF Frameworks draft spec, which is part of an event JWT claim, and requires the exclusion of "sub" (and "sub_id") usages for SETs

The SSF spec does require the exclusion of "sub" but it does not currently say anything about "sub_id". One potential way we could handle the conflict is to make "sub_id" a REQUIRED field of a SET and then let each event define a "subject" if it wants to. I think it is a mistake for SSF to restrict what MUST or MUST NOT be in an SSF event, because it will reduce interoperability down the line. The CAEP and RISC events do currently have "subject" defined. That's fine. Maybe other event types will want to follow that pattern, maybe they won't. But by using the "sub_id" claim in the top level JWT, as prescribed by the subject identifiers spec, we don't have to worry about how each future event type wants to be formatted.

from sharedsignals.

For ease of debate, I will state my last comment as a proposal.

Proposal

1. We make sub_id a REQUIRED top level claim of the SET for SSF messages.
2. We say that the authors of event types that get broadcast over SSF MAY define their schema in any way they see fit.
3. We deprecate (but do not yet remove) the subject claim from the CAPE and RISC event schemas.
4. We remove the language in the SSF spec that requires all events to have a subject claim.

from sharedsignals.