feat: use security requirement in map spec

[smizell]

Instead of defining security schemes within a map, people will define security requirements that reference security schemes defined within a provider definition.

Decisions

• I've included the type of the security scheme within the security requirement to make it explicit. Another option would be to only specify the security scheme identifier. However, this makes the security requirements less readable. It would also mean map tooling has to always reference the provider definition in order to know what type of scheme type a security requirement is.
• I've introduced a common definition of SecuritySchemeIdentifier which references the same identifier within a provider definition. We will reuse this as we create a provider specification.
• I've provided a few more context variables since the information will now be stored in the provider definition. For example, since the API key requirement relies on the placement found in the provider definition, we'll make that data available as a context variable.
• Important: this does not allow for multiple providers with the same security scheme IDs. We should discuss this point.

[vercel[bot]]

@smizell is attempting to deploy a commit to the Superface Team on Vercel.

To accomplish this, @smizell needs to request access to the Team.

Afterwards, an owner of the Team is required to accept their membership request.

[smizell]

@zdne I've removed keys, tokens, and passwords from the context variables for now.

[zdne]

@zdne I've removed keys, tokens, and passwords from the context variables for now.

Thanks! Could you please comment on https://github.com/superfaceai/spec/pull/12#pullrequestreview-581291888 ?

[smizell]

Here are some comments in relation to https://github.com/superfaceai/spec/pull/12#pullrequestreview-581291888

1. I went this way because my assumption was that it's the simplest because it's easier to read and easier on tooling to help people write against it. Otherwise, any authoring tooling would need the provider information to give people any kind of autocomplete for writing security requirements. However, I'll leave this to you to decide, I don't feel strongly either way and understand there are tradeoffs both way.
2. I was adding whatever information I could from the security scheme. However, after thinking through your question, it's probably better to leave out. We can always add later if people request it.
3. I haven't given any thought to it. Are you referencing something specific?

Per your comment:

I think this is not an issue because every Map is Provider (definition) -specific

If we ever allow a map to use multiple providers, this will mean that we would need some way to say which security scheme we're using in which provider. As it is right now, there's one provider per map so it doesn't matter. I'm fine with it as is. I just wanted to make sure you knew.

[zdne]

Thanks @smizell ! I think we are good to go here.

Only thing I'd consider is the support for custom auth schemes like mixes of bearer and api key and anything people can come up with.

One organizational point: If we would merge this into master we would loose the production (= what is currently implemented in the parser) spec. Should we create a preview or development integration branch here, for approved features in the spec that are not yet implemented?