arablocks / ara-identity Goto Github PK

Right now, it's not trivial to get an identity's Etherreum address, and has to be inferred from the DDO.

There should be a command that a user can use to get access to their Ethereum address, privateKey, and potentially Ethereum and Ara balances. This command should be hidden behind password verification.

Allow a keyring URL ie http://keyrings.ara.one/1.0/did:ara:59f8d0... to be passed in without a network name specified in the URL. Use the network name passed in via --network arg.

Desired Behavior

$ aid resolve did:ara:4d9a84... \
-k http://keyrings.ara.one/1.0/did:ara:59f8d...71a87987ef -n archiver -s test-node

Actual Behavior

$ aid resolve did:ara:4d9a84... \
-k http://keyrings.ara.one/1.0/did:ara:59f8d...71a87987ef/archiver -n resolver -s test-node

Expected Behavior

const araSecretKey = await aid.keystore.load(identity, 'ara')
const ethSecretKey = await aid.keystore.load(identity, 'eth')

Actual Behavior

N/A

Steps to Reproduce the Problem

1. N/A

getAuthenticationKey("did:ara:1b3d6e072f314de51cf78a35dbed4c64f5aef4a295b95b26a974e35db00972b0")
==>"120422878bd9a3f3a6442e98ce07e4f92c6c4863e86380de67957384312d9369"

DDO

{ '@context': 'https://w3id.org/did/v1',
  id: 'did:ara:1b3d6e072f314de51cf78a35dbed4c64f5aef4a295b95b26a974e35db00972b0',
  publicKey: 
   [ { id: 'did:ara:1b3d6e072f314de51cf78a35dbed4c64f5aef4a295b95b26a974e35db00972b0#owner',
       type: 'Ed25519VerificationKey2018',
       owner: 'did:ara:1b3d6e072f314de51cf78a35dbed4c64f5aef4a295b95b26a974e35db00972b0',
       publicKeyHex: '1b3d6e072f314de51cf78a35dbed4c64f5aef4a295b95b26a974e35db00972b0',
       publicKeyBase58: '2qLLXY6d1pL2TY5FpHokXxCeUZ2V3WmP248eqHXToq75',
       publicKeyBase64: 'Bs9bgcvMU3lHPeKNdvtTGT1rvSilblbJql0412wCXKw' } ],
  authentication: 
   [ { authenticationKey: 'did:ara:120422878bd9a3f3a6442e98ce07e4f92c6c4863e86380de67957384312d9369#owner',
       type: 'Ed25519VerificationKey2018' } ],
  service: [],
  created: '2018-07-20T15:44:33.696Z',
  updated: '2018-07-20T15:44:33.696Z',
  proof: 
   { type: 'Ed25519VerificationKey2018',
     nonce: 'f482e3a94be4958100215fb55f869ddf402b7fb3cc089f7dcd91fb2fc83de898',
     domain: 'ara',
     created: '2018-07-20T15:44:33.700Z',
     creator: 'did:ara:1b3d6e072f314de51cf78a35dbed4c64f5aef4a295b95b26a974e35db00972b0#owner',
     signatureValue: '756bd6a9e3760c441013a65fa4a8794d6e357189d146bfd1fa6b696754a6a65824b91be19a183a680d4731f3f2bd29e94923f54590883265e8d29c4055c57b01' } }

Expected Behavior

• Add a method isCorrectPassword() to verify an user's authorization through their password
• The verification would be done by decrypting the identity files by the user provided password

Expected Behavior

Create an shallow option in archive so that only the ddo is archived.

Specifications

• Version:
• Platform:
• Subsystem:

...resolving the local ddo.json file or resolving through an identity-resolver

Expected Behavior

DID - did:ara:7672be7dc9bcd6c6ca41abab4b70096eeba5a97a94f5d099ae723c081dfc96bb

aid resolve 7672be7dc9bcd6c6ca41abab4b70096eeba5a97a94f5d099ae723c081dfc96bb should resolve to a local ddo.json file or talk with an identity-resolver

Actual Behavior

aid resolve 7672be7dc9bcd6c6ca41abab4b70096eeba5a97a94f5d099ae723c081dfc96bb tries to do dns.resolve(did)

Steps to Reproduce the Problem

1. aid create
2. aid resolve <DID> (Run without the did:ara prefix)

Specifications

all

Expected Behavior

Could not resolve DID. No peer found... Ensure the DID has been archived.

Actual Behavior

http://18.212.152.190:8500/1.0/identifiers/did:ara:72e5d44c13101db201a1a46d82126af54c9bc23fa5c0f5281662e875c12ff9ba reason: Unexpected token T in JSON at position 0
...
ara: error: fatal: Could not resolve DID. No peer found

Steps to Reproduce the Problem

1. Try to resolve a DID remotely that has not been archived remotely

Specifications

• Version: 0.48 .3
• Platform:
• Subsystem:

An Abstract File System Access interface, or module will abstract reads (and writes) from the file system (or CFS/etc) to retrieve files like a ddo.json or keystore/ara. Abstracting this away allows the caller to consume these files, even if they do not live on the same host machine. This allows services running on servers to bind themselves to identities, without the identity files living on the same machine.

Expected Behavior

Attempting to a resolve an AraID that does not exist should throw

Actual Behavior

It crashes

Steps to Reproduce the Problem

1. Generate a DID string with the proper format (correct method, 64 chars in length) but that was not officially created
2. Attempt to resolve this DID
3. 😞

Specifications

all

Expected Behavior

did.normalize should throw if the input is not 64 chars in length

Actual Behavior

No error is thrown

Steps to Reproduce the Problem

1. const id = did.normalize('123') // id == 'did:ara:123'

Expected Behavior

When tests are run locally, the module shouldn't pick up any .ararc file in the system

Actual Behavior

No method to specify an .ararc file

Steps to Reproduce the Problem

https://github.com/AraBlocks/ara-identity/blob/master/test/archive.js#L12
The above test fails when the module picks an .ararc file with valid keyring opts

Readme documentation is stale, ara-context is no longer needed to be passed in to create function (and probably other functions).

Specifications

• Version: 0.47.1
• Platform:
• Subsystem:

Expected Behavior

Any operations in the CLI should be available easily in node by including the library in a node project and calling functions.

The CLI itself should not be polluted with any business logic or call components directly, and only be concerned with parsing arguments and outputting data.

Actual Behavior

The ara-identity CLI is directly calling operations on components (cfs, crypto, etc) without using any kind of view model.

Specifications

• Version: master
• Platform: all
• Subsystem: bin/ara-identity

Here is the code sample that triggers the error:

const did = { authentication: { type: kEd25519VerificationKey2018, publicKey } }
await aid.create({ context, password, did })

The stack is as follows:

  ara-filesystem:aid TypeError: First argument must be a string, Buffer, ArrayBuffer, Array, or array-like object.
  ara-filesystem:aid     at Function.Buffer.from (buffer.js:183:11)
  ara-filesystem:aid     at Object.decrypt (/Users/charles/Desktop/Development/Ara/ara-filesystem/node_modules/ara-network/secrets.js:245:23)
  ara-filesystem:aid     at findResolution (/Users/charles/Desktop/Development/Ara/ara-filesystem/node_modules/ara-identity/resolve.js:62:24)
  ara-filesystem:aid     at Object.resolve (/Users/charles/Desktop/Development/Ara/ara-filesystem/node_modules/ara-identity/resolve.js:52:18)
  ara-filesystem:aid     at <anonymous> +8ms

Expected Behavior

-q will only output errors and results

Actual Behavior

Doesn't exist

(Useful for integration testing, but I can find ways around it if others disagree)

Expected Behavior

n/a

Actual Behavior

The current output of aid create isn't easily used in shell scripts. If we had a --quiet (or something better named), aid create could be used in shell scripts.

There is a function signature in ethereum/keystore.js for recover without a body to it. I assume this function is to decrypt the hash found in a users .ara/identities/<hash>/keystore/eth file into their private key, which can then be used to pull out an address and public key.

The recover function would take two three arguments - password, keys and encryptedKeyStore. The first is the password the user set, the second is the JSON file stored in .ara/identities/<hash>/keys, and the third is the JSON file stored in .ara/identities/<hash>/keystore/eth. The password and keys will be passed into the decrypt method to return the secret key. The encryptedKeyStore, password, and secret key will be passed into the decrypt method to return a key object. That key object, along with the password, will be passed into keythereum.recover to return a buffer representing the users ethereum secret key.

The reason I want to complete this function is because for the content manager, in order to purchase content, we will need to access the user private key to sign transactions.