Add Receiver requirements to CAEP Interop Profile #315
Conversation
|
|
||
| #### Stream Control {#receivers-stream-control} | ||
|
|
||
| The following Stream Configuration API Methods MUST be supported: |
There was a problem hiding this comment.
I think CAEP Interop-compatible SSF receivers should also be able to delete streams they have created themselves.
Without support for a delete operation in the CAEP Interop profile, proprietary cleanup operations are always necessary.
The conformance tests currently also require support for stream deletion in order to be able to clean up appropriately after testing.
There was a problem hiding this comment.
So I propose to add:
**Deleting a Stream**
: Receivers MUST be able to delete a Stream on the Transmitter using valid
authorization.
There was a problem hiding this comment.
I agree on this. Let me add it
|
General comment: Instead of generic language such as "provide stream configuration", "provide current stream status", etc., should we specify the management API calls that need to be supported? E.g. "When a Receiver makes a Read Stream Configuration call as described in section 8.1.1.2 of the SSF spec to the Transmitter with valid authorization, the Transmitter MUST respond with a valid Stream Configuration as described in section 8.1.1. of the SSF spec. |
| ### Streams {#transmitter-common-stream-configuration} | ||
|
|
||
| In all streams created by the Transmitter, the following MUST be true: | ||
| For all streams requests received by the Transmitter, the following MUST be true: |
There was a problem hiding this comment.
"Management API calls" instead of "streams requests"?
| : A Receiver MUST be able to verify the liveness of the Stream by requesting | ||
| that the Transmitter send it a Stream Verification event by providing a valid | ||
| authorization | ||
| : A Transmitter MUST be able to support a Stream Verification event from a |
There was a problem hiding this comment.
Transmitters need to support the Stream Verification API method, and send the verification event. I think the language in this line conflates the two.
| Receivers MUST be able to accept events using: | ||
|
|
||
| * Push-Based Security Event Token (SET) Delivery Using HTTP {{RFC8935}} | ||
| * Poll-Based Security Event Token (SET) Delivery Using HTTP {{RFC8936}} |
There was a problem hiding this comment.
We should say "any one of the two transports", rather than both.
|
|
||
| ### JWKS URI {#receiver-jwks-uri} | ||
|
|
||
| The Receiver MUST obtain the signature key through the "jwks_uri" from the |
There was a problem hiding this comment.
The jwks_uri is optional for Transmitters, because Receivers can use poll delivery to receive unsigned events. I'm not sure whether we are supporting unsigned events in the interop spec, but please verify this.
There was a problem hiding this comment.
Though the profile mentions:
All events MUST be signed using the RS256 algorithm using a minimum of 2048-bit keys.
I dont see mention of unsigned events.
https://openid.net/specs/openid-caep-interoperability-profile-1_0-ID1.html#section-2.6
I agree. The organization is a bit lacking and i want to match the language a bit closer to SSF. |
3 participants
This PR starts to address adding Receiver requirements. More diffs will likely come in another PR.
Issue #294