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

Optional receiver_key to enable encryption of SETs #148

Closed
wants to merge 1 commit into from

Conversation

FragLegs
Copy link
Contributor

@FragLegs FragLegs commented Apr 2, 2024

  • Added optional receiver_key to enable encryption of SETs
  • Added language in Security Considerations section to describe when SETs MUST be encrypted
  • Added language in Security Considerations offering alternative methods of sharing the receiver's public key, including Dynamic Client Registration

During the WG meeting, we discussed using Dynamic Client Registration out-of-band to share the Receiver's public key with the Transmitter. However, that forces the Transmitter to use OAuth2, which we have intentionally tried to avoid in the spec. So instead I provided an optional in-spec method for sharing the Receiver's public key. For those who would prefer to use Dynamic Client Registration, I also added language to the Security Considerations section describing that as a potential option for secret sharing.

Fixes Issue #140

@FragLegs FragLegs requested review from timcappalli and tulshi April 2, 2024 13:38
@@ -1005,7 +1013,19 @@ Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo=
"urn:example:secevent:events:type_3",
"urn:example:secevent:events:type_4"
],
"description" : "Stream for Receiver A using events type_2, type_3, type_4"
"description": "Stream for Receiver A using events type_2, type_3, type_4",
"receiver_key": {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This example JWK was taken directly from the JWK spec: https://openid.net/specs/draft-jones-json-web-key-03.html#ExampleJWK

@FragLegs FragLegs changed the title Added optional receiver_key to enable encryption of SETs Optional receiver_key to enable encryption of SETs Apr 2, 2024
@@ -957,6 +958,11 @@ description
This is useful in multi stream systems to identify the stream for human actors. The
transmitter may truncate the string beyond allowed max length.

receiver_key
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. We are bringing in receiver-specific wording in the object, which is very stream-specific
  2. We should specifically call the key *_jwks_url to align with the Tx metadata key and disambiguate its purpose.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For more info, should we also reference the Encrypting SETs section?

## Encrypting SETs {#management-sec-encrypting-sets}
If an Event Transmitter is sending events that contain Personally Identifiable Information
(PII), whether in the body of the event or in the `sub_id` of the SET itself, then the
Transmitter MUST encrypt the SET such that it is sending a JWE instead of a JWT, as
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I generally agree that PII should be encrypted, is this really something that the spec should require?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The SET spec already requires it. See the second paragraph here: https://datatracker.ietf.org/doc/html/rfc8417#section-5.1

@FragLegs
Copy link
Contributor Author

Closing and will re-address if needed after release 1.0

@FragLegs FragLegs closed this Jun 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants