Update after move to new GitHub org

Signed-off-by: Stephen Curran <swcurran@gmail.com>

Author: swcurran

package.json

@@ -2,11 +2,11 @@
   "name": "indy-did-method",
   "description": "DID Indy DID Method Specification",
   "version": "0.1.0",
-  "homepage": "http://hyperledger.org",
+  "homepage": "https://www.lfdecentralizedtrust.org/",
   "license": "Apache 2",
   "repository": {
     "type": "git",
-    "url": "git://github.com/hyperledger/indy-did-method"
+    "url": "git://github.com/hyperledger-indy/indy-did-method"
   },
   "dependencies": {
     "spec-up": "0.10.6"

readme.md

@@ -1,6 +1,6 @@
 # Indy DID Method
 
-[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/hyperledger/indy-did-method)
+[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/hyperledger-indy/indy-did-method)
 
 This repository contains the source for the Indy DID Method specification. The initital content was transferred from a [collaborative HackMD document](https://hackmd.io/2IKUPROnRXW57Lmal_SGaQ).
 

spec/0_header.md

@@ -5,7 +5,7 @@ Indy DID Method
 
 **Latest Draft:**
 
-  [https://github.com/hyperledger/indy-did-method](https://github.com/hyperledger/indy-did-method)
+  [https://github.com/hyperledger-indy/indy-did-method](https://github.com/hyperledger-indy/indy-did-method)
 
 **Editors:**
 
@@ -25,7 +25,7 @@ Indy DID Method
 
 **Participate:**
 
-~ [GitHub repo](https://github.com/hyperledger/indy-did-method)
-~ [Commit history](https://github.com/hyperledger/indy-did-method/commits/main)
+~ [GitHub repo](https://github.com/hyperledger-indy/indy-did-method)
+~ [Commit history](https://github.com/hyperledger-indy/indy-did-method/commits/main)
 
 ------------------------------------

spec/10_original_did_operations.md

@@ -1,6 +1,6 @@
 ## did:indy Operations
 
-There is a description of types and operations that are available in case of using [`indy-node`](https://github.com/hyperledger/indy-node) with [`indy-plenum`](https://github.com/hyperledger/indy-plenum) repositories.
+There is a description of types and operations that are available in case of using [`indy-node`](https://github.com/hyperledger-indy/indy-node) with [`indy-plenum`](https://github.com/hyperledger-indy/indy-plenum) repositories.
 
 ### Creation
 
@@ -32,7 +32,7 @@ The NYM transaction `version` is distinct from the DID version described [below]
 
 #### Backwards Compatibility
 
-Prior to `did:indy`, the unenforced convention in the [Indy SDK](https://github.com/hyperledger/indy-sdk) was to use the following to demonstrate the relationship between the DID and its initial verkey: `For an Ed25519 key: Convert into Base58char the first 16 bytes of the 256 bit public key (verkey).` If the `did:indy` approach to verifying the relationship between the DID and its initial verkey fail, a client resolving a DID MAY attempt to verify the relationship using the old Indy SDK convention.
+Prior to `did:indy`, the unenforced convention in the [Indy SDK](https://github.com/hyperledger-indy/indy-sdk) was to use the following to demonstrate the relationship between the DID and its initial verkey: `For an Ed25519 key: Convert into Base58char the first 16 bytes of the 256 bit public key (verkey).` If the `did:indy` approach to verifying the relationship between the DID and its initial verkey fail, a client resolving a DID MAY attempt to verify the relationship using the old Indy SDK convention.
 
 When using the old Indy SDK convention of using the first 16 bytes of the verkey, related convention allowed for the placement of a shortened verkey (prefixed with `~`) in the NYM `verkey` field, such that the full verkey was dynamically generated by combining the DID and shortened verkey. That convention is **NOT** used in "did:indy", but client resolvers using DIDs created prior to `did:indy` MUST detect and convert shortened verkeys to full verkeys as necessary.
 

spec/11_besu_did_operations.md

@@ -1,6 +1,6 @@
 ## did:indy:besu Operations
 
-There is a description of a storage format, types and operations that are available in case of using [`indy-besu`](https://github.com/hyperledger/indy-besu) repository.
+There is a description of a storage format, types and operations that are available in case of using [`indy-besu`](https://github.com/hyperledger-indy/indy-besu) repository.
 
 ### Storage format
 

spec/15_security_considerations.md

@@ -76,7 +76,7 @@ Residual risks for Hyperledger Indy include:
 
 ### Integrity protection and update authentication for method operations and write authorization
 
-For all write operations that alter the ledger data(Create, Update, Deactivate) the appropriate signatures are needed, where the DIDs and Verification Method public keys (`verkey`s) of the signatories must be one the ledger. The client signs the body of the [write request](https://github.com/hyperledger/indy-node/blob/master/docs/source/requests.md#reply-structure-for-write-requests) (`txn`) for indy-node and [EIP1559 transactions](https://besu.hyperledger.org/23.4.0/public-networks/concepts/transactions/types#eip1559-transactions) for indy-besu, depending on the configured ledger rules, some transactions might require signatures from multiple DIDs. The Indy ledger processes the signed write request and the software enforces the integrity protection by checking the validity of the given signatures and their authorization. No authentication or authorization is required for read requests.
+For all write operations that alter the ledger data(Create, Update, Deactivate) the appropriate signatures are needed, where the DIDs and Verification Method public keys (`verkey`s) of the signatories must be one the ledger. The client signs the body of the [write request](https://github.com/hyperledger-indy/indy-node/blob/master/docs/source/requests.md#reply-structure-for-write-requests) (`txn`) for indy-node and [EIP1559 transactions](https://besu.hyperledger.org/23.4.0/public-networks/concepts/transactions/types#eip1559-transactions) for indy-besu, depending on the configured ledger rules, some transactions might require signatures from multiple DIDs. The Indy ledger processes the signed write request and the software enforces the integrity protection by checking the validity of the given signatures and their authorization. No authentication or authorization is required for read requests.
 
 As indy-node currently only provides a single `verkey` for authentication, this exposes a risk of loss of control if the  private key for the DID Controller is lost.
 
@@ -94,7 +94,7 @@ No endpoint authentication is used other than the trusted node keys from the gen
 
 ### Protection of data
 
-Transaction data on the ledger stored by the nodes is protected for integrity by maintaining cryptographically signed root hashes of the [merkle tree](https://github.com/hyperledger/indy-plenum/blob/master/docs/source/storage.md) for indy-plenum and [Ethereum merkle tree](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) for indy-besu, that includes all transactions of the ledger. Data is not protected for integrity as all data is inherently public anyway.
+Transaction data on the ledger stored by the nodes is protected for integrity by maintaining cryptographically signed root hashes of the [merkle tree](https://github.com/hyperledger-indy/indy-plenum/blob/master/docs/source/storage.md) for indy-plenum and [Ethereum merkle tree](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) for indy-besu, that includes all transactions of the ledger. Data is not protected for integrity as all data is inherently public anyway.
 
 ### Protection of Key Material
 
@@ -104,7 +104,7 @@ The ledger nodes are operating with the Validator BLS key, which is stored in so
 
 ### Peer-to-Peer Computing resources
 
-The RBFT algorithm in indy-plenum was initially designed as a robust Consensus protocol that limits the effect of malicious nodes. However, this requires some computations that limits the efficiency and scalability of the consensus. It ist strongly advised to not increase the number of validator nodes above 25. Hyperledger Indy was designed with very limited number of write requests, but very efficient read requests (only one node needs to be queried). If scalability issues still arise, the concept of [Observer nodes](https://github.com/hyperledger/indy-plenum/blob/master/design/observers.md) can be implemented.
+The RBFT algorithm in indy-plenum was initially designed as a robust Consensus protocol that limits the effect of malicious nodes. However, this requires some computations that limits the efficiency and scalability of the consensus. It ist strongly advised to not increase the number of validator nodes above 25. Hyperledger Indy was designed with very limited number of write requests, but very efficient read requests (only one node needs to be queried). If scalability issues still arise, the concept of [Observer nodes](https://github.com/hyperledger-indy/indy-plenum/blob/master/design/observers.md) can be implemented.
 
 For networking Hyperledger Indy Besu uses Hyperledger Besu. It implements Ethereum's devp2p network protocols for inter-client communication, along with an additional sub-protocol for IBFT2 consensus:
 - Discovery: A UDP-based protocol for finding peers on the network

spec/3_indy_ledger_object_glossary.md

@@ -62,8 +62,8 @@ credential validation and can be [read](https://hyperledger-indy.readthedocs.io/
 [[def: Indy VDR]]
 
 ~ Hyperledger Indy VDR (for "Verifiable Data Registry") is an open source implementation of an Indy client/resolver for both DIDs and other Indy objects.
-The repository is called indy-vdr and can be found [here](https://github.com/hyperledger/indy-vdr).
+The repository is called indy-vdr and can be found [here](https://github.com/hyperledger-indy/indy-vdr).
 
 [[def: Indy Besu VDR]]
 
-~ Hyperledger Indy Besu VDR (for "Verifiable Data Registry") is an open source implementation of an Indy Besu client/resolver for both DIDs and other Indy objects. The repository is called indy-besu contains Indy Besu VDR [here](https://github.com/hyperledger/indy-besu/tree/main/vdr).
+~ Hyperledger Indy Besu VDR (for "Verifiable Data Registry") is an open source implementation of an Indy Besu client/resolver for both DIDs and other Indy objects. The repository is called indy-besu contains Indy Besu VDR [here](https://github.com/hyperledger-indy/indy-besu/tree/main/vdr).

spec/4_differences_from_did_sov.md

@@ -30,7 +30,7 @@ The idea is using of a basic mapping between other DIDs identifiers and Ethereum
 
 ### Migration from `did:indy` to `did:indy:besu`
 
-At some point company managing (Issuer,Holder,Verifier) decide to migrate from [Indy Node](https://github.com/hyperledger/indy-node) to [Indy Besu Ledger](https://github.com/hyperledger/indy-besu).
+At some point company managing (Issuer,Holder,Verifier) decide to migrate from [Indy Node](https://github.com/hyperledger-indy/indy-node) to [Indy Besu Ledger](https://github.com/hyperledger-indy/indy-besu).
 
 In order to do that, their Issuer's applications need to publish their data to Indy Besu Ledger.
 Issuer need to run migration tool manually (on the machine containing Indy Wallet storing Credential Definitions) which migrate data.

spec/7_indy_did_method_identifiers.md

@@ -3,7 +3,7 @@
 The did:indy Method DID identifier has four components that are concatenated to make a DID specification conformant identifier. The components are:
 
 - **DID**: the hardcoded string `did:` to indicate the identifier is a DID.
-- **DID Indy Method**: the hardcoded string `indy:` indicating that the identifier uses this DID Method specification. The hardcoded string `indy:besu:` indicates the use of [`indy-besu`](https://github.com/hyperledger/indy-besu) implementation for Indy DID Method.
+- **DID Indy Method**: the hardcoded string `indy:` indicating that the identifier uses this DID Method specification. The hardcoded string `indy:besu:` indicates the use of [`indy-besu`](https://github.com/hyperledger-indy/indy-besu) implementation for Indy DID Method.
 - **DID Indy Namespace**: a string that identifies the name of the primary Indy ledger, followed by a `:`. The namespace string may optionally have a secondary ledger name prefixed by a `:` following the primary name. If there is no secondary ledger element, the DID resides on the primary ledger, else it resides on the secondary ledger. By convention, the primary is a production ledger while the secondary ledgers are non-production ledgers (e.g. staging, test, development) associated with the primary ledger. Examples include, `sovrin`, `sovrin:staging` and `idunion`.
 - **Namespace Identifier**: an identifier unique to the given DID Indy namespace. 
   - The identifier may be self-certifying, meaning that the identifier is derived from the initial verkey associated with the identifier. See the [DID Creation](#nym-transaction-version) section of this document for the derivation details.

spec/8_other_indy_ledger_object_identifiers.md

@@ -32,7 +32,7 @@ The following sections cover each ledger object type, providing:
 - notes about the elements of the pre-`did:indy` identifier.
 
 This first version of the `did:indy` DID Method will use an `<object-family>` value of `anoncreds` and an `<object-family-version>` of `v0` to match the
-pre-specification, open source version of anoncreds as implemented in the [indy-sdk](https://github.com/hyperledger/indy-sdk/tree/master/docs/design/002-anoncreds).
+pre-specification, open source version of anoncreds as implemented in the [indy-sdk](https://github.com/hyperledger-indy/indy-sdk/tree/master/docs/design/002-anoncreds).
 Later versions of the `did:indy` specification will use a higher `<object-family-version>` as the AnonCreds standardization work proceeds
 and the required dependency on Hyperledger Indy is removed. In this initial version, the DID URLs are closely aligned with the existing object identifiers.