On 28/10/2019 22:06, Benjamin Kaduk wrote:
32.) Section 5.6.1The client sends a POST request to the token endpoint at the AS. The profile MUST specify how the communication is protected. The content In the previous section we said that maybe even other transports than coaps or https would be possible; are we limited to those that have POST verbs? Also, a similar comment as above about what attributes the protection entails seems to apply.[LS] This will need a major rephrasing of the text. I see two options here: 1.) We rewrite all parts to use a neutral language in general and specify POST/GET etc. for transports that have these verbs. 2.) We state in the beginning that transports that do not use RESTful verbs should use the best equivalent. Option 1. would get a bit cluncky, while option 2. might be a bit confusing Do you have a specific preference? [JLS] I would suggest that this could fall under the punt to the new transport that does not have the same as these verbs in it to explain how they would map.I agree that (1) is more effort than it's likely to be worth. If we can finagle a single-sentence disclaimer like "transports that do not use these verbs will need to specify the requisite behavior" that would be great; if not, then we can consider whether to just ignore it or do something more complicated.
I'll go for this: " Note that this document specifies protocol exchanges in terms of RESTful commands such as GET and POST. Future profiles using protocols that do not support these verbs MUST specify how the corresponding protocol messages are transmitted instead. " In the Overview section where we mention alternate transport protocols. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
