feat: introduce verify_service(java) and demo_webapp(node) into at_login

at_login_verify_service/.gitignore

@@ -0,0 +1,29 @@
+### IntelliJ IDEA ###
+out/
+!**/src/main/**/out/
+!**/src/test/**/out/
+
+### Eclipse ###
+.apt_generated
+.classpath
+.factorypath
+.project
+.settings
+.springBeans
+.sts4-cache
+bin/
+!**/src/main/**/bin/
+!**/src/test/**/bin/
+
+### NetBeans ###
+/nbproject/private/
+/nbbuild/
+/dist/
+/nbdist/
+/.nb-gradle/
+
+### VS Code ###
+.vscode/
+
+### Mac OS ###
+.DS_Store

at_login_verify_service/CONTRIBUTING.md

@@ -0,0 +1,170 @@
+<img width=250px src="https://atsign.dev/assets/img/atPlatform_logo_gray.svg?sanitize=true">
+
+# Contributing guidelines
+
+We 💙 [Pull Requests](https://help.github.com/articles/about-pull-requests/)
+for fixing issues or adding features. Thanks for your contribution!
+
+Please read our [code of conduct](code_of_conduct.md), which is based on
+[![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.0-4baaaa.svg)](code_of_conduct.md)
+
+
+For small changes, especially documentation, you can simply use the "Edit" button
+to update the Markdown file, and start the
+[pull request](https://help.github.com/articles/about-pull-requests/) process.
+Use the preview tab in GitHub to make sure that it is properly
+formatted before committing. Please use conventional commits and follow the semantic PR format as documented 
+[here](https://github.com/atsign-foundation/.github/blob/trunk/atGitHub.md#semantic-prs).
+A pull request will cause integration tests to run automatically, so please review
+the results of the pipeline and correct any mistakes that are reported.
+
+If you plan to contribute often or have a larger change to make, it is best to
+setup an environment for contribution, which is what the rest of these guidelines
+describe. The atsign-foundation GitHub organization's conventions and configurations are documented
+[here](https://github.com/atsign-foundation/.github/blob/trunk/atGitHub.md).
+
+## Development Environment Setup
+
+
+### Prerequisites
+
+   ``` sh
+   # show how to install the tools needed to work with the code here
+   ```
+
+
+### GitHub Repository Clone
+
+To prepare your dedicated GitHub repository:
+
+1. Fork in GitHub https://github.com/atsign-foundation/at_libraries
+2. Clone *your forked repository* (e.g., `git clone git@github.com:yourname/at_libraries`)
+3. Set your remotes as follows:
+
+   ```sh
+   cd at_libraries
+   git remote add upstream git@github.com:atsign-foundation/at_libraries.git
+   git remote set-url upstream --push DISABLED
+   ```
+
+   Running `git remote -v` should give something similar to:
+
+   ```text
+   origin  git@github.com:yourname/at_libraries.git (fetch)
+   origin  git@github.com:yourname/at_libraries.git (push)
+   upstream        git@github.com:atsign-foundation/at_libraries.git (fetch)
+   upstream        DISABLED (push)
+   ```
+
+   The use of `upstream --push DISABLED` is to prevent those
+   with `write` access to the main repository from accidentally pushing changes
+   directly.
+
+### Development Process
+
+1. Fetch latest changes from main repository:
+
+   ```sh
+   git fetch upstream
+   ```
+
+1. Reset your fork's `trunk` branch to exactly match upstream `trunk`:
+
+   ```sh
+   git checkout trunk
+   git reset --hard upstream/trunk
+   git push --force
+   ```
+
+   **IMPORTANT**: Do this only once, when you start working on new feature as
+   the commands above will completely overwrite any local changes in `trunk` content.
+1. Edit, edit, edit, and commit your changes to Git:
+
+   ```sh
+   # edit, edit, edit
+   git add *
+   git commit -m 'A useful commit message'
+   git push
+   ```
+
+1. How to run tests:
+
+   ``` sh
+   # explain tests here
+   ```
+
+1. Open a new Pull Request to the main repository using your `trunk` branch
+
+
+## @‎library release process
+
+The Atsign Foundation produces several widgets and libraries that the app developer
+can make use of to develop apps on @‎protocol. These libraries are developed in
+Dart & Flutter and published to [pub.dev](https://pub.dev/publishers/atsign.org/packages).
+
+![alt_text](images/image1.png "Version flow")
+
+## Following the changes
+
+The Atsign Foundation publishes libraries and widgets to
+[https://pub.dev/publishers/atsign.org/packages](https://pub.dev/publishers/atsign.org/packages).
+Each of these libraries contains a tab called “Changelog” that shows various
+published versions and a short description of what changes that went in.
+
+![alt_text](images/image2.png "Changelog screenshot")
+
+Also the “Versions” tab shows the versions published in the reverse
+chronological order.
+
+![alt_text](images/image3.png "Versions screenshot")
+
+## Reporting a bug
+
+The best place to start reporting bugs on the libraries published by 
+@‎protocol would be the “View/report issues” link available on
+[pub.dev](https://pub.dev/publishers/atsign.org/packages).
+
+![alt_text](images/image4.png "View/report issues highlight")
+
+Once the link is clicked, one should be redirected to GitHub repo where the
+issue can be reported by clicking on the “New issue” button.
+
+![alt_text](images/image5.png "Issues list")
+
+Clicking on the  “New issue” button should take you to the screen to choose
+where the issue is a Bug or an Enhancement.
+
+![alt_text](images/image6.png "Choose Bug report")
+
+Upon clicking on the “Get started” button against the “Bug Report” you should
+be directed to a page with a bug template provided by Atsign. Filling
+out all of the fields in the template gives Atsign a better chance to
+reproduce and fix the bug.
+
+![alt_text](images/image7.png "Filling a Bug report")
+
+## Bug fix and delivery process
+
+* Bugs will initially be placed into the Sprint Planning Board so that they
+can be triaged, estimated and scheduled.
+* Once work on a bug is scheduled one or more engineers will be assigned to
+fixing the bug, and story points will be allocated to match the time estimated
+to fix the bug.
+* Progress on fixing the bug will be updated in the associated GitHub issue,
+and reviewed during subsequent sprint planning meetings where necessary.
+* Once a fix is created we will work with the reporter to ensure that the fix
+is appropriate to their needs, and where possible this should happen prior to
+release to pub.dev
+
+## Closure of the bug
+
+* Where possible the issue associated with the bug should be closed by mutual
+consent with the reporter. This could be:
+    * The reporter closing the issue because they have found a workaround.
+    * The reporter closing the issue because they are satisfied with a fix
+    provided.
+    * A team member closes the issue after the reporter leaves a comment
+    indicating that they are happy for it to be closed.
+* If the reporter does not respond within 14 calendar days then we must assume
+that they no longer have an interest in fixing the bug and work in progress can
+be closed out at the team’s discretion.

at_login_verify_service/LICENSE

@@ -0,0 +1,29 @@
+BSD 3-Clause License
+
+Copyright (c) 2020, The @ Foundation
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice, this
+   list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright notice,
+   this list of conditions and the following disclaimer in the documentation
+   and/or other materials provided with the distribution.
+
+3. Neither the name of the copyright holder nor the names of its
+   contributors may be used to endorse or promote products derived from
+   this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

at_login_verify_service/README.md

@@ -0,0 +1,96 @@
+<img width=250px src="https://atsign.dev/assets/img/atPlatform_logo_gray.svg?sanitize=true">
+
+# at_login key_verification
+
+## Overview:
+
+A simple library to verify if a key exists in an atPlatform Secondary Server. This library can start REST-service for information exchange/.
+## Get started:
+
+### Pre-requisites
+Java needs to be installed
+
+### Clone it from github
+
+Feel free to fork a copy of the source from the [GitHub Repo](https://github.com/atsign-foundation/at_login)
+
+### Installation:
+
+This library is built with maven. Run the following in PROJECT_ROOT command to build the project
+
+```shell
+mvn install
+```
+### Output
+The jar executable will be generated in PROJECT_ROOT/target with the following name
+```
+atlogin-verify-service-1.0-jar-with-dependencies
+```
+
+## Usage
+
+### Staring the REST Service
+
+```shell
+java -jar target/atlogin-verify-service-1.0-jar-with-dependencies  startRest
+```
+The REST Server has now been started on your localhost in port=4567
+
+### Using the REST Service
+All the end-points only accept POST Requests. Make sure to send a body with the request
+
+#### 1) Generate
+To generate a KeyValue pair of a random UUID that can be used as a verification token.
+This end-point accepts a request with a jsonBody containing an entry atsign
+
+The following shell command can be used to send a POST request to the REST end-point:
+
+```shell
+curl -i localhost:4567/generate -X POST -H 'Content-Type: application/json' -d '{"atsign":"@alice"}'
+
+```
+Response:
+```
+{"key":"public:_4d5afb79-7d0f-4b0a-b7c0-cf732d66b501.atlogin@alice","value":"e3def62c-f583-4747-a777-95091b361464"}
+```
+
+#### 2) Verify
+This end-point can to used to verify if a Key with given Value exists in an atSign's secondary. This end-point accepts a request with a jsonEncoded body that has the following fields - atsign, key, value.
+
+The following shell command can be used to send a POST request to the REST end-point:
+
+```shell
+curl -i localhost:4567/verify -X POST -H 'Content-Type: application/json' -d '{"atsign":"@libra98extended", "key":"public:_159e24c1-66b8-4889-8840-4601b489c115.atlogin@alice", "value":"b45fcf00-b89f-4ce9-8001-6bca575dd5f2"}'
+
+```
+Response Case-success:
+```
+{
+"responseType" : "success",
+"verificationStatus" : "true"
+}
+```
+Response Case-failure:
+```
+{
+"responseType" : "failure",
+"error" : "Error while verifying",
+"cause" : "java.lang.ClassCastException",
+"verificationStatus" : "false"
+}
+```
+#### 3) Stop
+This end-point STOPS the REST service. This request does not need a body
+
+The following shell command can be used to send a POST request to the REST end-point:
+```shell
+curl -i localhost:4567/stop -X POST
+```
+Response:
+```
+true
+```
+## Open source usage and contributions
+
+This is freely licensed open source code, so feel free to use it as is, suggest changes or enhancements or create your
+own version. See CONTRIBUTING.md for detailed guidance on how to setup tools, tests and make a pull request.

at_login_verify_service/SECURITY.md

@@ -0,0 +1,41 @@
+<img width=250px src="https://atsign.dev/assets/img/atPlatform_logo_gray.svg?sanitize=true">
+
+# Atsign Foundation Open Source Security Policies and Procedures
+
+This document outlines security procedures and general policies for the
+Atsign Foundation Open Source projects as found on
+https://github.com/atsign-foundation.
+
+  * [Reporting a Vulnerability](#reporting-a-vulnerability)
+  * [Disclosure Policy](#disclosure-policy)
+
+## Reporting a Vulnerability 
+
+The Atsign Foundation team and community take all security vulnerabilities
+seriously. Thank you for improving the security of our open source 
+software. We appreciate your efforts and responsible disclosure and will
+make every effort to acknowledge your contributions.
+
+Report security vulnerabilities by emailing the Atsign security team at:
+
+    security@atsign.com
+
+The lead maintainer will acknowledge your email within 24 hours, and will
+send a more detailed response within 48 hours indicating the next steps in 
+handling your report. After the initial reply to your report, the security
+team will endeavor to keep you informed of the progress towards a fix and
+full announcement, and may ask for additional information or guidance.
+
+Please report security vulnerabilities in third-party modules to the person
+or team maintaining the module.
+
+## Disclosure Policy
+
+When the security team receives a security bug report, they will assign it
+to a primary handler. This person will coordinate the fix and release
+process, involving the following steps:
+
+  * Confirm the problem and determine the affected versions.
+  * Audit code to find any potential similar problems.
+  * Prepare fixes for all releases still under maintenance. These fixes
+    will be released as fast as possible to pub.dev where applicable.