Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Receiver to supply public key #140

Open
FragLegs opened this issue Feb 9, 2024 · 10 comments
Open

Allow Receiver to supply public key #140

FragLegs opened this issue Feb 9, 2024 · 10 comments
Labels

Comments

@FragLegs
Copy link
Contributor

FragLegs commented Feb 9, 2024

In the current SSF spec, the Transmitter can make a jwks.json file available to its Receivers. This allows the Transmitter to sign the JWTs that it is sending the Receiver, so that the Receiver can verify that the security event tokens (SETs) are not forged by some third party. However, these security event tokens often contain personally identifying information (PII) and some vendors may wish to be able to encrypt the SET, not just sign it. In order to do that, the Transmitter would need the Receiver to share a public key. I propose that we add language to the spec to make it clear that a Receiver MAY provide well-known and jwks.json endpoints for this purpose.

The current spec treats Receivers as an afterthought - all of the language is around what Transmitters MAY and MUST do. This would give us an opportunity to make Receivers more of a first class citizen in the SSF spec.

@appsdesh
Copy link
Contributor

appsdesh commented Feb 9, 2024

I have raised similar asks around not having reciever's metadata doc in earlier working group calls here

SET encryption should also be baked in the SET - RFC8417 or outside SSF spec.

On the encryption - my thoughts are

  1. To encrypt the events object, but for that to work, we need to surface stream ID as a first-class claim in the SET JWT that could be used for routing. (Sounds like RFC8417 enhancement)
  2. We should define at what granularity we should support encryption, per stream unique keys, per receiver unique keys, etc.

@TakahikoKawasaki
Copy link

In a traditional way like the OpenID Connect Dynamic Client Registration 1.0 specification (OIDC DynReg), an entity that receives encrypted data does either (1) register its public key in advance to the entity that encrypts data (e.g. through the jwks client metadata in the case of OIDC DynReg) or (2) make its public key publicly available and convey the location of the key to the entity that encrypts data (e.g. through the jwks_uri client metadata in the case of OIDC DynReg).

A new flexible way adopted by the OpenID for Verifiable Credential Issuance specification (OID4VCI) is to include a public key for encryption in a request at runtime through a dedicated parameter. In the case of OID4VCI, the parameter is credential_response_encryption. The value of the parameter is a JSON object that contains the following properties.

property description
jwk A public key in the JWK (RFC 7517) format.
alg A JWE (RFC 7516) alg algorithm.
enc A JWE (RFC 7516) enc algorithm.

This new approach may be worth considering.

@FragLegs
Copy link
Contributor Author

@TakahikoKawasaki That is a great way to solve this problem! We could add an optional, receiver-supplied field to the StreamConfiguration (to be set by the receiver on stream creation or stream update) that holds the JSON object you described above. I like this solution better because it is a lower burden on the Receiver, especially a poll-based Receiver who might not be hosting any endpoints.

@appsdesh I am imagining that the Transmitter would encrypt the entire SET. That is, instead of just signing the JWT (making it a JWS) the Transmitter would encrypt and sign the JWT (making it a JWE). Do you think there would be problems with that approach? Some of the PII is potentially in the top level of the SET (i.e. the sub_id claim) so I think we need to encrypt more than just the events.

@FragLegs FragLegs changed the title Proposal to add jwks.json to Receiver Allow Receiver to supply public key Feb 12, 2024
@awoie
Copy link

awoie commented Feb 26, 2024

+1 to enabling optional encryption.

@windley
Copy link

windley commented Feb 26, 2024

+1 to optional encryption and I also like. @TakahikoKawasaki's suggestion.

@dhs-aws
Copy link

dhs-aws commented Feb 26, 2024

This has also come up in the work on using SETs within SCIM. I agree that we need to support a mechanism for encryption of the SETs to protect data in transit, particularly where there is TLS termination at an endpoint prior to the receiver.

@ysarig1
Copy link
Collaborator

ysarig1 commented Apr 4, 2024

Encrypting the entire SET using a public key can be expensive to the transmitter if there are a large number of security events that need to be encrypted. While I expect that the volume of security events will usually be fairly low there are edge cases (e.g., device compliance events when the definition of compliance changed and resulted with a large number of devices changing their status).

Another option that we can consider for encryption is for the receiver to send a symmetric encryption key to the transmitter when the stream is created.

BTW If I remember correctly, the JWE spec include the use of a symmetric key to do the plaintext encryption.

@TakahikoKawasaki
Copy link

The JWE spec (RFC 7516) has already implemented a logic to minimize the amount of data for asymmetric encryption. The following diagram is an excerpt from "4.1. Two-Step Encryption" in "Understanding ID Token". (DISCLAIMER: It's my blog post in November, 2017)

encrypted_key

@dhs-aws
Copy link

dhs-aws commented Apr 9, 2024

@ysarig1 wrote

Encrypting the entire SET using a public key can be expensive to the transmitter if there are a large number of security events that need to be encrypted. While I expect that the volume of security events will usually be fairly low there are edge cases (e.g., device compliance events when the definition of compliance changed and resulted with a large number of devices changing their status).

As discussed, this is an option, not a requirement, for transmitters. Cost is controllable by the transmitter if they wish to not support encrypting the SETs.

In many cases the risk of data leakage or being out of compliance outweighs the expense of encryption. Supporting this as a first class mechanism in SSF will expand the utility of SSF with no cost to those who choose not to implement it.

@tulshi tulshi added enhancement New feature or request spec:SSF labels Apr 20, 2024
@keylimesoda
Copy link

@TakahikoKawasaki That is a great way to solve this problem! We could add an optional, receiver-supplied field to the StreamConfiguration (to be set by the receiver on stream creation or stream update) that holds the JSON object you described above. I like this solution better because it is a lower burden on the Receiver, especially a poll-based Receiver who might not be hosting any endpoints.

@appsdesh I am imagining that the Transmitter would encrypt the entire SET. That is, instead of just signing the JWT (making it a JWS) the Transmitter would encrypt and sign the JWT (making it a JWE). Do you think there would be problems with that approach? Some of the PII is potentially in the top level of the SET (i.e. the sub_id claim) so I think we need to encrypt more than just the events.

Regarding granularity, I could foresee a scenario where encryption is particularly desired for certain subjects within a stream, and that certain subjects may even have their own associated public keys.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

10 participants