Optional receiver_key to enable encryption of SETs #148
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
FragLegs
commented
Apr 2, 2024
| @@ -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": { | |||
There was a problem hiding this comment.
This example JWK was taken directly from the JWK spec: https://openid.net/specs/draft-jones-json-web-key-03.html#ExampleJWK
FragLegs
changed the title
appsdesh
reviewed
Apr 16, 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 | |||
There was a problem hiding this comment.
- We are bringing in receiver-specific wording in the object, which is very stream-specific
- We should specifically call the key
*_jwks_urlto align with the Tx metadata key and disambiguate its purpose.
There was a problem hiding this comment.
For more info, should we also reference the Encrypting SETs section?
timcappalli
reviewed
Apr 23, 2024
| ## 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 |
There was a problem hiding this comment.
While I generally agree that PII should be encrypted, is this really something that the spec should require?
There was a problem hiding this comment.
The SET spec already requires it. See the second paragraph here: https://datatracker.ietf.org/doc/html/rfc8417#section-5.1
|
Closing and will re-address if needed after release 1.0 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
receiver_keyto enable encryption of SETsDuring 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