-
Notifications
You must be signed in to change notification settings - Fork 16
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
Conversation
@@ -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.
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
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- We are bringing in receiver-specific wording in the object, which is very stream-specific
- We should specifically call the key
*_jwks_url
to align with the Tx metadata key and disambiguate its purpose.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
Closing and will re-address if needed after release 1.0 |
receiver_key
to 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