Merge branch 'master' into master

Jenkinsfile.cd

@@ -41,7 +41,7 @@ def testing() {
     stage('Testing') {
         parallel([
                 'ubuntu-test' : { ubuntuTesting() },
-                'redhat-test' : { rhelTesting() },
+                //  FIXME 'redhat-test' : { rhelTesting() }, https://jira.hyperledger.org/browse/IS-1212
                 'android-test': { androidTesting() },
                 'windows-test': { windowsTesting() },
                 'ios-test'    : { iosTesting() }
@@ -1140,22 +1140,23 @@ def nodejsWrapperPublishing(testEnv, isRelease, library) {
 
     def suffix = getSuffix(isRelease, "nodejs")
 
-    dir(paths[library]['dir']) {
-        testEnv.inside {
-            if (library == 'vcx') { // need addition step for VCX to create .js files
-                sh "npm run compile"
-            }
+    def directory = paths[library]['dir']
 
-            npmPublish(version, suffix)
+    testEnv.inside {
+        if (library == 'vcx') { // need addition step for VCX to create .js files
+            sh "cd $directory && npm i && npm run compile"
         }
+
+        npmPublish(version, suffix, directory)
     }
 }
 
-def npmPublish(version, suffix) {
+def npmPublish(version, suffix, directory) {
     withCredentials([file(credentialsId: 'npm_credentials', variable: 'credentialsFile')]) {
         sh 'cp $credentialsFile ~/.npmrc'
-        sh "npm version --no-git-tag-version --allow-same-version $version$suffix"
-        sh "npm publish"
+        sh "cd $directory && " +
+        "npm version --no-git-tag-version --allow-same-version $version$suffix &&" +
+                "npm publish"
     }
 }
 

Jenkinsfile.ci

@@ -12,12 +12,12 @@ def testing() {
     }
     stage('Testing') {
         parallel([
-            'ubuntu-test' : { ubuntuTesting() },
-            'android-test': { androidTesting() },
-            'macos-test'  : { macosTesting() },
-            'ios-test'    : { iosTesting() },
-            'redhat-test' : { rhelTesting() },
-            'windows-test': { windowsTesting() }
+                'ubuntu-test' : { ubuntuTesting() },
+                'android-test': { androidTesting() },
+                'macos-test'  : { macosTesting() },
+                'ios-test'    : { iosTesting() },
+                //  FIXME 'redhat-test' : { rhelTesting() }, https://jira.hyperledger.org/browse/IS-1212
+                'windows-test': { windowsTesting() }
         ])
     }
 }

docs/getting-started/indy-walkthrough.md

@@ -64,11 +64,11 @@ The ledger is intended to store **Identity Records** that describe a **Ledger En
 
 In this tutorial we will use two types of DIDs. The first one is a **Verinym**. A **Verinym** is associated with the **Legal Identity** of the **Identity Owner**. For example, all parties should be able to verify that some DID is used by a Government to publish schemas for some document type. The second type is a **Pseudonym** - a **Blinded Identifier** used to maintain privacy in the context of an ongoing digital relationship (**Connection**). If the Pseudonym is used to maintain only one digital relationship we will call it a Pairwise-Unique Identifier. We will use Pairwise-Unique Identifiers to maintain secure connections between actors in this tutorial.
 
-The creation of a DID known to the Ledger is an **Identity Record** itself (NYM transaction). The NYM transaction can be used for creation of new DIDs that is known to that ledger, the setting and rotation of a verification key, and the setting and changing of roles. The most important fields of this transaction are `dest` (target DID), `role` (role of a user NYM record being created for) and the `verkey` (target verification key). See [Requests](https://github.com/hyperledger/indy-node/blob/master/docs/requests.md) to get more information about supported ledger transactions.
+The creation of a DID known to the Ledger is an **Identity Record** itself (NYM transaction). The NYM transaction can be used for creation of new DIDs that is known to that ledger, the setting and rotation of a verification key, and the setting and changing of roles. The most important fields of this transaction are `dest` (target DID), `role` (role of a user NYM record being created for) and the `verkey` (target verification key). See [Requests](https://github.com/hyperledger/indy-node/blob/master/docs/source/requests.md) to get more information about supported ledger transactions.
 
 Publishing with a DID verification key allows a person, organization or thing, to verify that someone owns this DID as that person, organization or thing is the only one who knows the corresponding signing key and any DID-related operations requiring signing with this key.
 
-Our ledger is public permissioned and anyone who wants to publish DIDs needs to get the role of **Trust Anchor** on the ledger. A **Trust Anchor** is a person or organization that the ledger already knows about, that is able to help bootstrap others. (It is *not* the same as what cybersecurity experts call a "trusted third party"; think of it more like a facilitator). See [Roles](https://github.com/hyperledger/indy-node/blob/master/docs/auth_rules.md) to get more information about roles.
+Our ledger is public permissioned and anyone who wants to publish DIDs needs to get the role of **Trust Anchor** on the ledger. A **Trust Anchor** is a person or organization that the ledger already knows about, that is able to help bootstrap others. (It is *not* the same as what cybersecurity experts call a "trusted third party"; think of it more like a facilitator). See [Roles](https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md) to get more information about roles.
 
 **The first step towards being able to place transactions on the ledger involves getting the role of Trust Anchor on the ledger. Faber College, Acme Corp and Thrift Bank will need to get the role of Trust Anchor on the ledger so they can create Verinyms and Pairwise-Unique Identifiers to provide the service to Alice.**
 

docs/index.rst

@@ -31,6 +31,8 @@ Find the other Indy docs at https://hyperledger-indy.readthedocs.io
   build-guides/index.rst
   migration-guides/index.rst
   architecture/index.rst
+  zh/indy-walkthrough-zh.md
+
 
 
 .. toctree::

docs/zh/indy-walkthrough-zh.md

@@ -0,0 +1,29 @@
+
+# 什麼是 Indy 和 Libindy，還有為什麼它們那麼重要？
+
+Indy 提供一個私密、安全、身份的生態系統，而Libindy 為它提供客戶端。Indy 使人 -- 而不是傳統機構 -- 控制他們的個人資料以及如何公開。它令各種創新變得可能：授權、嶄新的支付流程、資產及文件管理、不同形式的委託、聲譽累積、與其他新技術整合等等。
+
+Indy使用開源的分佈賬戶技術。這個賬戶是由一群參與者合作建立的一種數據庫，而非一個中央管理的大規模數據庫。數據冗餘地存在於多個地方，而由多部參與的電腦（機器）的交易所構成，透過大而有力的加密標準加以保護。它的設計充分使用密鑰管理和網絡安全的最佳實踐模式。所得的結果是一個可靠、公共的信任源頭，不受單一個體所控制，系統堅實而不受人侵駭入，足以抵禦其他個體敵意的破壞和顛覆。
+
+如果你對加密學概念和區塊鏈技術還有疑惑，不用害怕，這指南會給你介紹Indy的主要概念，你來對地方了。
+
+## 我们要讨论什么？
+我们的目标是向你介绍很多关于 Indy 的概念，帮助你来理解让这一起工作起来的背后的原因。
+
+我们会将整个过程编为一个故事。Alice，一个虚构的 Faber 大学的毕业生，想要应聘一家虚构的公司 Acme Corp 的一份工作。当她获得了这份工作后，她想要向 Thrift 银行申请一笔贷款，这样她就可以购买一辆汽车了。在工作申请表单上，她想用她的大学成绩单作为受过教育证明，并且一旦被录用后，Alice 想使用被雇佣的事实来作为申请贷款的信誉凭证。
+
+在当今的世界里，身份信息以及信任交互非常混乱，它们很慢，与隐私性相违背，容易受到欺诈。我们将会展示给你 Indy 是如何让这些产生了巨大的进步。
+
+作为 Faber 大学的毕业生，Alice 收到了一封毕业生的 newsletter，从中了解到她的母校可以提供数字成绩单（digital transcripts）。她登录了学校的毕业生网站，通过点击 获得成绩单 按钮，她申请了自己的成绩单。（其他的发起这个请求的方式还可能包括扫描一个 QR code，从一个公共的 URL 下载一份打包的成绩单，等等）
+
+## About Alice
+
+Alice 还没有意识到，想要使用这个数字的成绩单，她需要一个新的类型的身份信息 - 并不是 Faber 大学存储在在校（on-campus）数据库中为她创建的传统的身份信息，而是一个属于她自己的全新的便携的身份信息，独立于所有的过去和将来的关系，不经过她的允许，没有人能够废除（revoke）、指派（co-opt）或者关联（correlate）这个身份信息。这就是一个 自我主权的身份信息（self-sovereign identity），也是 Indy 的核心功能。
+
+在常规的情况下，管理一个自我主权的身份信息会要求使用 一个工具，比如一个桌面的或者手机的应用程序。它可能是一个独立的应用，或者使用一个第三方的服务机构（代理商）提供的账本服务。Sovrin 基金会（Sovrin Foundation）发布了一个这种类型的工具。Faber 大学了解了这些需求，并会建议 Alice 安装一个 Indy app 如果她没有安装过的话。这个 app 会作为点击 获得成绩单 按钮之后的工作流中的一部分而被安装。
+
+在常规的情况下，管理一个自我主权的身份信息会要求使用 一个工具，比如一个桌面的或者手机的应用程序。它可能是一个独立的应用，或者使用一个第三方的服务机构（代理商）提供的账本服务。Sovrin 基金会（Sovrin Foundation）发布了一个这种类型的工具。Faber 大学了解了这些需求，并会建议 Alice 安装一个 Indy app 如果她没有安装过的话。这个 app 会作为点击 获得成绩单 按钮之后的工作流中的一部分而被安装。
+
+
+当 Alice 点击了 获得成绩单 按钮后，她会下载一个带有一个 Indy 连接请求 的文件。这个连接请求文件的扩展名为 .indy，并且会和 Alice 的 Indy app 相关联，将会允许 Alice 创建跟另外一个在这个账本生态圈（ledger ecosystem）存在的一方（Faber 大学）的一个安全的信息沟通频道（channel）。
+