Updates to Security Metadata Proposal

w3c / wot-security

a repo exclusively for security to better manage issues and security considerations for WoT

https://w3c.github.io/wot-security/

18 stars 22 forks source link

Updates to Security Metadata Proposal #88

Closed mmccool closed 6 years ago

mmccool commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

mmccool commented 6 years ago

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.

sebastiankb commented 6 years ago

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 commented 6 years ago

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