Updates to Security Metadata Proposal

[mmccool]

• Allow name:value pairs for security configurations, enabled by JSON-LD 1.1 frames
• Convert as -> authorizationUrl, ts -> tokenUrl, and rs -> refreshUrl. The shorter names are nicer but "rs" has a conflict with "Resource Server" that it is best to avoid, and these names are consistent with OpenAPI.

[mmccool]

• update examples to more closely follow new name:value style for interactions with separate property/action/event sections in TDs rather than using a single array and @type values
• show use of "definitions" section to group security configurations
• formatting cleanup and minor tweaks to text

[mmccool]

Still need to fix certain things in the examples; waiting for updates to main TD examples.

[mmccool]

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.

[ereshetova]

I think this is really now in shape for merging to the working branch as proposal. It should be much easier for people to see and find it this way.

[sebastiankb]

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?

[mmccool]

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).