Closed mmccool closed 6 years ago
Pros: client/server can cooperate to pick higher-security option they both support. But they probably would anyway, since usually the "best" version is obvious. Cons: an attacker would just pick the worst option, of course. Priorities would help them... but again, they would probably already have a good idea of the worst case.
My overall feeling is that priorities would add verbosity without much benefit. If we DO add them, I would add them as an extension (additional set of tags) for special purpose use rather than adding complexity to the current set of tags.
Note also that "security" in the above can mean different things: 1. security of authentication/authorization 2. security against evesdropping
So, there is still some benefit for 2 from cooperating client/server pairs picking the "best" option for encryption (for example), but 1 can help an attacker to pick the "worst" option to defeat authentication. My comments about "but they would probably know the best options for their purposes anyway" apply to both cases.
We discussed this in the Security TF and felt that priorities caused more problems than they would solve and we should leave them out.
Note: there is already an implicit ordering of forms, as implementations will tend to work down the list from first to last, and stop on the first one that "works". The security TF does not feel that any additional scheme for prioritizing forms is worth the additional complexity, so we are closing this issue with a "No".
(from Michael Lagally): should security schemes have priorities, so when options are available (eg an OR combination with multiple forms), the highest-security option is chosen?