Update identity rfcs

ghoshbishakh · ghoshbishakh · commit e6736100fee8 · 2021-09-24T15:54:44.000+05:30
Signed-off-by: Bishakh Ghosh &lt;ghoshbishakh@gmail.com&gt;
diff --git a/rfcs/formats/identity.md b/rfcs/formats/identity.md
@@ -5,9 +5,9 @@
  -->
 # Identity Plane Data Formats
 
-* Authors: Bishakh Chandra Ghosh, Venkatraman Ramakrishna, Krishnasuri Narayanam
-* Status: Draft
-* Since: 25-July-2021
+* Authors: Bishakh Chandra Ghosh, Venkatraman Ramakrishna, Krishnasuri Narayanam, Ermyas Abebe
+* Status: Proposed
+* Since: 24-September-2021
 
 
 ## Participant Unit Identity
diff --git a/rfcs/models/identity/decentralized-network-identity-discovery-management.md b/rfcs/models/identity/decentralized-network-identity-discovery-management.md
@@ -6,8 +6,8 @@
 # Decentralized Network-Identity Discovery and Management for Interoperation
 
 * Authors: Venkatraman Ramakrishna, Krishnasuri Narayanam, Bishakh Chandra Ghosh, Ermyas Abebe
-* Status: Draft
-* Since: 10-June-2020
+* Status: Proposed
+* Since: 24-September-2021
 
 
 # Overview
@@ -127,7 +127,7 @@ The DLT networks and its participant units must create and configure their ident
 
 ## Network Identity Discovery
 
-To allow seamless interoperation across two different DLT networks, the identity of the counterparty networks have to be configured. But, even before that, some means of discovering the networks is required through which any identity protofocl can start. Discovery of networks in the identity plane is facilitated by discovery of the Network Identity, which are represented as Network DIDs and registered in the IINs. Each Network thus has a unique Network DID which can be considered equivalent to a domain name in Internet parlance. Thus Network DID facilitate discovery of networks with the help of the IIN infrastructure.
+To allow seamless interoperation across two different DLT networks, the identity of the counterparty networks have to be configured. But, even before that, some means of discovering the networks is required through which any identity protocol can start. Discovery of networks in the identity plane is facilitated by discovery of the Network Identities, which are represented as Network DIDs and registered in the IINs. Each Network thus has a unique Network DID which can be considered equivalent to a domain name in Internet parlance. Thus Network DID facilitates discovery of networks with the help of the IIN infrastructure.
 
 The network discovrery protocols specifications are elaborated [here](../../protocols/discovery/readme.md).
 
diff --git a/rfcs/models/identity/identity-update-policy.md b/rfcs/models/identity/identity-update-policy.md
@@ -6,8 +6,8 @@
 # Network Identity Update Policies
 
 * Authors: Bishakh Chandra Ghosh, Venkatraman Ramakrishna, Krishnasuri Narayanam, Ermyas Abebe
-* Status: Draft
-* Since: 25-July-2021
+* Status: Proposed
+* Since: 24-September-2021
 
 ## updatePolicy
 
diff --git a/rfcs/models/identity/iin-agent.md b/rfcs/models/identity/iin-agent.md
@@ -5,9 +5,9 @@
  -->
 # IIN Agents in a DLT Network
 
-* Authors: Venkatraman Ramakrishna
-* Status: Draft
-* Since: 15-Oct-2020
+* Authors: Venkatraman Ramakrishna, Krishnasuri Narayanam, Bishakh Chandra Ghosh, Ermyas Abebe
+* Status: Proposed
+* Since: 24-September-2021
 
 
 # Summary
@@ -34,12 +34,12 @@ This view is illustrated in the figure below (Fig.1), which maps quite naturally
 
 The following artifacts in the data plane are relevant to identity plane protocols:
 * _Identity trust store_: this is a set of IINs and Trust anchors `<IIN>,<Trust-Anchor-DID>`. It implies that the network trusts a given trust anchor or all trust anchors in a given IIN to certify the identity/membership credentials of foreign network units. 
-<!-- * Each network unit can be described directly by the network ID and a DID or the set can be described using a pattern (like a regular expression; e.g., Kleene closure `*`).  -->
+
 * The IIN definition can additionally contain peer connectivity information (to access the IIN ledger). This data will be looked up in the identity sharing protocol, while fetching membership information for a foreign network. It can also be used in proof verification (or view validation) in data plane protocols.
 * _Foreign network identities and configurations_: these are [security groups](../security.md), containing identities and certificates corresponding to a foreign network's units. (_Each security group is augmented with a DID attribute denoting the identity owned by the IIN Agent associated with this network unit/security group_). The IIN Agent of the network participants together update these configurations from the identity plane information.
 
 
-# Indy implementation of IIN Agent
+# Hyperledger Indy implementation of IIN Agent
 
 An IIN Agent represents a network unit that is also a self-certified identity provider for some subset of the network, as stated earlier in the summary. It is simultaneously an IIN (Indy) client and a network (Fabric, Corda, etc.) client. Therefore, there are different ways in which it can be implemented, but its core feature is that it lies within the trust boundary of a root identity provider of a network.
 
diff --git a/rfcs/models/identity/iin.md b/rfcs/models/identity/iin.md
@@ -5,9 +5,9 @@
  -->
 # Interoperation Identity Network
 
-* Authors: Venkatraman Ramakrishna, Bishakh Chandra Ghosh, Krishnasuri Narayanam
-* Status: Draft
-* Since: 15-Oct-2020
+* Authors: Venkatraman Ramakrishna, Bishakh Chandra Ghosh, Krishnasuri Narayanam, Ermyas Abebe
+* Status: Proposed
+* Since: 24-September-2021
 
 
 # Summary
@@ -58,22 +58,6 @@ For each verifiable credential, the IIN must store the corresponding [schema](ht
 
 
 
-
-<!-- 
-An IIN contains the following:
-* Identity record: `<DID>,<Service-Endpoint>` for each of the following:
-  * Every steward
-  * (If applicable) every trust anchor created by a steward of this IIN
-  * Every network unit certified by a steward or a trust anchor of this IIN
-* Credential schemas corresponding to the following:
-  * Membership list for a network, with the following attributes: `<Network-ID>`, `[<DID1>,<DID2>,......]`
-  * Membership info for a network unit, with the following attributes: `<Network-ID>` (_Currently, this is the only attribute relevant for identify information sharing, but we can add more for other kinds of information sharing_)
-* Credential definitions corresponding to the following:
-  * Membership list for a network: signing (issuing) key owned by a steward or trust anchor of this IIN
-  * Membership information for a network unit: signing (issuing) key owned by a steward or trust anchor of this IIN
-  * 
-  *  -->
-
 # IIN DID Method
 
 An IIN can have any distributed DID registry based on any platform, provided it supports the DID method operations stated as follows: 
@@ -108,34 +92,3 @@ These trust anchors are entities that the participants trust and whose identity
 ## IIN Agents
 
 DLT networks interact with the IINs through a components called IIN Agent. Each participant unit in a DLT network has have atleast one IIN Agent using which it exposes its identity as well as discovers and verifies foreign network identities. The IIN Agents are detailed [here](./iin-agent.md).
-
-
-<!-- 
-# IIN Structure and Bootstrap
-
-This is a Hyperledger Indy network that is collectively managed by a set of _stewards_. For an IIN to facilitate bilateral interoperation between networks N1 and N2, the following constraint must hold: _for every unit in N1 and N2, there exists at least one steward that is trusted, directly or transitively, by that network unit_.
-
-In the limiting, or trivial, case, an IIN can contain just one steward that is trusted by every unit in N1 and N2. For the purpose of our protocol, such a network would be functionally indistinguishable from, though less trustworthy than, a truly distributed IIN that contains multiple stewards representing trusted authorities that have agreed to join that IIN and are bound by a shared ledger.
-
-_Proposal for initial implementation_: Build an IIN that contains four Indy nodes (as per the reference Indy implementation) and two stewards. This implementation will be non-trivial and will have one steward corresponding to each interoperating network (i.e., consortium) in at least some demo scenarios. _Example_: for interoperation between TradeLens and We.Trade, we build an IIN containing two stewards by default: one representing Maersk (to certify TradeLens units) and another representing IBM (to certify We.Trade units). -->
-
-<!-- 
-## Bootstrap procedure:
-1. Create network artifacts:
-   * Configuration file with network name (`NETWORK_NAME`) set to `IIN`(or something unique, if there is more than one IIN)
-   * Keys for each Indy node: ed25519 transport/communication keys, BLS keys for multisig and state proofs
-   * Genesis transactions: pool transactions genesis file, domain transactions genesis file with specification for stewards (each with a unique name assigned a priori) 
-2. Launch the 4-node Indy pool network by starting each node in a separate Docker container.
-3. Start an IIN steward agent for each steward in a separate Docker container. A steward agent is built on a Hyperledger Aries instance.
-
-## Reference:
-* Hyperledger Indy Node: Create a Network and Start a 4-Node Indy Pool [link](https://hyperledger-indy.readthedocs.io/projects/node/en/latest/start-nodes.html)
-* Implementation of single-node/single-steward Indy pool in Docker containers [link](https://github.com/identity-interop/iin_deployment)
-
-
-
-
-# Interfaces
-Standard Indy SDK API will be used for communication between identity owners' agents and between agents and Indy pool nodes.
-Standard Indy SDK API will be used for creating and maintaining wallets (for DIDs, keys, secrets, and credentials) at the agents. 
--->
diff --git a/rfcs/protocols/discovery/readme.md b/rfcs/protocols/discovery/readme.md
@@ -4,8 +4,8 @@
  SPDX-License-Identifier: CC-BY-4.0
  -->
 # Discovery Protocol
-* Authors: Bishakh Chandra Ghosh, Venkatraman Ramakrishna, Krishnasuri Narayanam
-* Status: Draft
+* Authors: Bishakh Chandra Ghosh, Venkatraman Ramakrishna, Krishnasuri Narayanam, Ermyas Abebe
+* Status: Proposed
 * Since: 25-July-2021
 
 
diff --git a/rfcs/protocols/identity/data-plane-identity-configuration.md b/rfcs/protocols/identity/data-plane-identity-configuration.md
@@ -1,8 +1,8 @@
 # Data Plane Identity Configuration
 
-* Authors: Venkatraman Ramakrishna, Krishnasuri Narayanam, Bishakh Chandra Ghosh
-* Status: Draft
-* Since: 20-August-2021
+* Authors: Venkatraman Ramakrishna, Krishnasuri Narayanam, Bishakh Chandra Ghosh, Ermyas Abebe
+* Status: Proposed
+* Since: 24-September-2021
 
 ### Overview
 
diff --git a/rfcs/protocols/identity/identity-change-updates.md b/rfcs/protocols/identity/identity-change-updates.md
@@ -1,8 +1,8 @@
 # Credentials update with changes in identity plane
 
-* Authors: Venkatraman Ramakrishna, Krishnasuri Narayanam, Bishakh Chandra Ghosh
-* Status: Draft
-* Since: 10-June-2020
+* Authors: Venkatraman Ramakrishna, Krishnasuri Narayanam, Bishakh Chandra Ghosh, Ermyas Abebe
+* Status: Proposed
+* Since: 24-September-2021
 
 
 # Overview
diff --git a/rfcs/protocols/identity/network-identity-validation.md b/rfcs/protocols/identity/network-identity-validation.md
@@ -1,9 +1,9 @@
 
 ## Network Identity Validation
 
-* Authors: Venkatraman Ramakrishna, Krishnasuri Narayanam, Bishakh Chandra Ghosh
-* Status: Draft
-* Since: 10-June-2020
+* Authors: Venkatraman Ramakrishna, Krishnasuri Narayanam, Bishakh Chandra Ghosh, Ermyas Abebe
+* Status: Proposed
+* Since: 24-September-2021
 
 ### Summary
 When a network ("local network" from here on) tries to configure the idetntity of another network ("foreign network" from here on) for interoperation, the broad steps involved are (i) Network Discovery (ii) Network Identity Validation. Both these steps are carried out by the IIN agent of the participants of the local network.
diff --git a/rfcs/protocols/identity/readme.md b/rfcs/protocols/identity/readme.md
@@ -5,9 +5,9 @@
  -->
 # Protocols for Decentralized Network-Identity Configuration, Exchannge and Validation, for Interoperation
 
-* Authors: Venkatraman Ramakrishna, Krishnasuri Narayanam, Bishakh Chandra Ghosh
-* Status: Draft
-* Since: 10-June-2020
+* Authors: Venkatraman Ramakrishna, Krishnasuri Narayanam, Bishakh Chandra Ghosh, Ermyas Abebe
+* Status: Proposed
+* Since: 24-September-2021
 
 
 ## Summary
