diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index db3aedc67..8ad8aff46 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -170,7 +170,7 @@ must be a pull request.
 * Consensus the solution is preferred
 * Resolution of identified concerns and challenges
 * Precisely described with spec edits
-* Compliant implementation in [AsyncAPI JS Parser](https://www.github.com/asyncapi/parser-js) (might not be merged)
+* Compliant implementation in the [AsyncAPI JS Parser](https://www.github.com/asyncapi/parser-js) and the [AsyncAPI JSON Schema](https://github.com/asyncapi/asyncapi-node) (might not be merged)
 
 A *proposal* becomes a *draft* when the set of problems or drawbacks have been
 fully considered and accepted or resolved, and the solution is deemed
@@ -190,13 +190,13 @@ feature without explicit opt-in when possible.
 An RFC at the *accepted* stage is a completed solution. According to a spec
 Committer it is ready to be merged as-is into the spec document. The RFC is
 ready to be deployed in AsyncAPI libraries. An *accepted* RFC must be
-implemented in the [AsyncAPI JS Parser](https://www.github.com/asyncapi/parser-js).
+implemented in the [AsyncAPI JS Parser](https://www.github.com/asyncapi/parser-js) and the [AsyncAPI JSON Schema](https://github.com/asyncapi/asyncapi-node).
 
 *Entrance criteria:*
 
 * Consensus the solution is complete
 * Complete spec edits, including examples and prose
-* Compliant implementation in [AsyncAPI JS Parser](https://www.github.com/asyncapi/parser-js) (fully tested and merged or ready to merge)
+* Compliant implementation in the [AsyncAPI JS Parser](https://www.github.com/asyncapi/parser-js) and the [AsyncAPI JSON Schema](https://github.com/asyncapi/asyncapi-node) (fully tested and merged or ready to merge)
 
 A *draft* is *accepted* when the Committers have been convinced via
 implementations and tests that it appropriately handles all edge cases; that the
@@ -234,7 +234,7 @@ mean it has to be the only person working on it though. They
 are a "person of reference" for a given RFC implementation and
 may or may not know about JS, relying on the help of other
 community members to implement the RFC on the
-[JS Parser](https://www.github.com/asyncapi/parser-js).
+[AsyncAPI JS Parser](https://www.github.com/asyncapi/parser-js) and the [AsyncAPI JSON Schema](https://github.com/asyncapi/asyncapi-node).
 
 
 
diff --git a/spec/asyncapi.md b/spec/asyncapi.md
index b9c84e2bc..f61827c21 100644
--- a/spec/asyncapi.md
+++ b/spec/asyncapi.md
@@ -25,7 +25,7 @@ user/signedup:
     $ref: "#/components/messages/userSignUp"
 ```
 
-It means that the [application](#definitionsApplication) allows [consumers](#definitionsConsumer) to subscribe to the `user/signedup` [channel](#definitionsChannel) to receive userSignUp [messages](#definitionsMessage).
+It means that the [application](#definitionsApplication) allows [consumers](#definitionsConsumer) to subscribe to the `user/signedup` [channel](#definitionsChannel) to receive userSignUp [messages](#definitionsMessage) produced by the application.
 
 **The AsyncAPI specification does not assume any kind of software topology, architecture or pattern.** Therefore, a server MAY be a message broker, a web server or any other kind of computer program capable of sending and/or receiving data. However, AsyncAPI offers a mechanism called "bindings" that aims to help with more specific information about the protocol.
 
@@ -60,6 +60,7 @@ It means that the [application](#definitionsApplication) allows [consumers](#def
       - [Message Object](#messageObject)
       - [Message Trait Object](#messageTraitObject)
       - [Tags Object](#tagsObject)
+      - [Tag Object](#tag-object)
       - [External Documentation Object](#externalDocumentationObject)
       - [Components Object](#componentsObject)
       - [Reference Object](#referenceObject)
@@ -67,6 +68,7 @@ It means that the [application](#definitionsApplication) allows [consumers](#def
       - [Security Scheme Object](#securitySchemeObject)
       - [Security Requirement Object](#security-requirement-object)
       - [OAuth Flows Object](#oauth-flows-object)  
+      - [OAuth Flow Object](#oauth-flow-object)
       - [Server Bindings Object](#serverBindingsObject)
       - [Parameters Object](#parametersObject)
       - [Parameter Object](#parameterObject)
@@ -81,13 +83,13 @@ It means that the [application](#definitionsApplication) allows [consumers](#def
 ## <a name="definitions"></a>Definitions
 
 #### <a name="definitionsApplication"></a>Application
-An application is any kind of computer program or a group of them. It MUST be a [producer](#definitionsProducer), a [consumer](#definitionsConsumer) or both. An application MAY be a microservice, IoT device (sensor), mainframe process, etc. An application MAY be written in any number of different programming languages as long as they support the selected [protocol](#definitionsProtocol). An application MUST also use a protocol supported by the server in order to connect and exchange [messages](#definitionsMessage).
+An application is any kind of computer program or a group of them. It MUST be a [producer](#definitionsProducer), a [consumer](#definitionsConsumer) or both. An application MAY be a microservice, IoT device (sensor), mainframe process, etc. An application MAY be written in any number of different programming languages as long as they support the selected [protocol](#definitionsProtocol). An application MUST also use a protocol supported by the server in order to connect and exchange [messages](#definitionsMessage). 
 
 #### <a name="definitionsProducer"></a>Producer
-A producer is a type of application, connected to a server, that is creating [messages](#definitionsMessage) and addressing them to [channels](#definitionsChannel). A producer MAY be publishing to multiple channels depending on the server, protocol, and use-case pattern. 
+A producer is a type of application, connected to a server, that is creating [messages](#definitionsMessage) and addressing them to [channels](#definitionsChannel). A producer MAY be publishing to multiple channels depending on the server, protocol, and use-case pattern.
 
 #### <a name="definitionsConsumer"></a>Consumer
-A consumer is a type of application, connected to a server via a supported [protocol](#definitionsProtocol), that is consuming [messages](#definitionsMessage) from [channels](#definitionsChannel). A consumer MAY be consuming from multiple channels depending on the server, protocol, and the use-case pattern. 
+A consumer is a type of application, connected to a server via a supported [protocol](#definitionsProtocol), that is consuming [messages](#definitionsMessage) from [channels](#definitionsChannel). A consumer MAY be consuming from multiple channels depending on the server, protocol, and the use-case pattern.
 
 #### <a name="definitionsMessage"></a>Message
 A message is the mechanism by which information is exchanged via a channel between servers and applications. A message MUST contain a payload and MAY also contain headers. The headers MAY be subdivided into [protocol](#definitionsProtocol)-defined headers and header properties defined by the application which can act as supporting metadata. The payload contains the data, defined by the application, which MUST be serialized into a format (JSON, XML, Avro, binary, etc.). Since a message is a generic mechanism, it can support multiple interaction patterns such as event, command, request, or response. 
@@ -555,8 +557,8 @@ Field Name | Type | Description
 ---|:---:|---
 <a name="channelItemObjectRef"></a>$ref | `string` | Allows for an external definition of this channel item. The referenced structure MUST be in the format of a [Channel Item Object](#channelItemObject). If there are conflicts between the referenced definition and this Channel Item's definition, the behavior is *undefined*.
 <a name="channelItemObjectDescription"></a>description | `string` | An optional description of this channel item. [CommonMark syntax](http://spec.commonmark.org/) can be used for rich text representation.
-<a name="channelItemObjectSubscribe"></a>subscribe | [Operation Object](#operationObject) | A definition of the SUBSCRIBE operation.
-<a name="channelItemObjectPublish"></a>publish | [Operation Object](#operationObject) | A definition of the PUBLISH operation.
+<a name="channelItemObjectSubscribe"></a>subscribe | [Operation Object](#operationObject) | A definition of the SUBSCRIBE operation, which defines the messages produced by the application and sent to the channel.
+<a name="channelItemObjectPublish"></a>publish | [Operation Object](#operationObject) | A definition of the PUBLISH operation, which defines the messages consumed by the application from the channel.
 <a name="channelItemObjectParameters"></a>parameters | [Parameters Object](#parametersObject) | A map of the parameters included in the channel name. It SHOULD be present only when using channels with expressions (as defined by [RFC 6570 section 2.2](https://tools.ietf.org/html/rfc6570#section-2.2)).
 <a name="channelItemObjectBindings"></a>bindings | [Channel Bindings Object](#channelBindingsObject) \| [Reference Object](#referenceObject) | A map where the keys describe the name of the protocol and the values describe protocol-specific definitions for the channel.
 
@@ -645,7 +647,9 @@ subscribe:
 
 #### <a name="operationObject"></a>Operation Object
 
-Describes a publish or a subscribe operation. This provides a place to document how and why messages are sent and received. For example, an operation might describe a chat application use case where a user sends a text message to a group.
+Describes a publish or a subscribe operation. This provides a place to document how and why messages are sent and received.
+
+For example, an operation might describe a chat application use case where a user sends a text message to a group. A publish operation describes messages that are received by the chat application, whereas a subscribe operation describes messages that are sent by the chat application.
 
 ##### Fixed Fields