Change:
... while we use (property, values) pairs to set other properties? Is there a reason for this? Otherwise I suggest we agree to one interaction model!
Related I also think this text isn't really that correct: "Security decisions, especially pertaining to trust, are not static. Once configured, parameters may also be supplied during connection establishment. These are best handled as client-provided callbacks." You can update some security parameter anytime during the connection using the same interface as before. However the two callbacks we have defined require actually actions that follow an event, so they have to be callbacks.
"However the two callbacks we have defined require actually actions that follow an event, so they have to be callbacks." - that's it, these need to be callbacks. NAME made them like that because using them requires a tighter interaction model. See issue .
As discussed in interim, Security Parameters are a bit different from selection properties. We should review the security parameter interface, but it will likely be independent.
I did a closer review on these and there are two main differences between Security Parameters and the other Preferences / Events: Use of individual calls on security parameters instead of add with keywor. These could easily be integrated, e.g., by turning into Use of Callbacks instead of Events – closed as Issue . Despite there is no technical reason to not turn the Security Callbacks into events, events that "need to do something", i.e., accept, reject, or return an identity, really look wired. Let's discuss which way to take this one forward: Leave as is Align the interface of SecurityParameters to the Transport Parameters, but keep them as a separate object and leave SecurityCallbacks as they are Integrate the interface of SecurityParameters into the Transport Parameters, but keep SecurityCallbacks roughly the same Integrate the interface of SecurityParameters into the Transport Parameters, make SecurityCallbacks more event-like. I am happy to make a PR for whatever we decide, but not for all of them.
We can do the minor option to change AddCiphersuite to Add(ciphersuite...)
Maybe add clarification text to say that these are pre-connection only parameters
Consider cutting cache lifetime, etc, from this list
We really should explicitly add a sentence to clearly say that the security functions are configured using add functions and not via Properties. This is so useful to say, so that someone does not come along and do this because they think we just didn't see this.
closed with
lgtm, will let NAME merge it though.

Discussion:
transport-security, many transport security protocols require specific security parameters and constraints from the client at the time of configuration and actively during a handshake.  These <del> configuration parameters are created as follows: </del> <ins> configuration parameters need to be specified in the pre-connection phase and are created as follows: </ins> Security configuration parameters and sample usage follow:

system.  Parameters include: ciphersuites, supported groups, and signature algorithms. <del> Session cache management: Used to tune cache capacity, lifetime, re-use, and eviction policies, e.g., LRU or FIFO.  Constants and policies for these interfaces are implementation-specific. </del> Pre-Shared Key import: Used to install pre-shared keying material established out-of-band.  Each pre-shared keying material is associated with some identity that typically identifies its use or has some protocol-specific meaning to the Remote Endpoint. <ins> Session cache management: Used to tune cache capacity, lifetime, re-use, and eviction policies, e.g., LRU or FIFO.may also me changed, but are implementation-specific. </ins> 5.3.2. Security decisions, especially pertaining to trust, are not static.