Closed mmccool closed 6 years ago
Still need to fix certain things in the examples; waiting for updates to main TD examples.
Ready for another round of reviews, and I'd like to do a merge. There are some significant changes from the first version; I just added a separate "securityDefinitions" block and made other changes that make this version of the proposal consistent with and backward compatible with the current TD spec.
I just started to include the security terms in the TD code model. I wonder if the term "scheme" is somehow redundant, if we also have the name of the scheme (e.g., 'apikey', 'basic') as part of the key name as in apikeyConfig, basicConfig etc? If the term scheme is really required I would propose to define a super class 'securityConfig' that contains common used config terms. So far this would make sense for 'scheme' and 'in', right?
Under the revised proposal a configuration can be given without any key (tag). Also, in general there could be more than one config using the same scheme. So yes, I think we need “scheme”. I agree it DOES seem a little redundant but under the revised proposal keys (named configurations) are only used in securityDefinitions which can be considered an optional “convenience” feature (and only important in very complex configurations).