Identity RFC & Research

[satazor]

This is a proposal for an identity management system for Peer-Star, named Peer-Star-Identity. It's built upon standards to provide a good foundation for Peer-Star applications to authenticate and identify users.

I'm very excited to hear all of your feedback!

[fritzy]

It's unclear to me how the identity-manager is aware of all of the devices? Say they're using uport -- which has an attested DID, is this their root identity and key? How does that get them a list of other devices that they logged in with? Are they going to use their ethereum key as their root key? The web3 sign method doesn't work in any gateway that I've tried.

It's very unclear to me how the identity-manager is a) going to be aware of other device entries b) going to be able to sign new identities for existing users

[satazor]

It's unclear to me how the identity-manager is aware of all of the devices?

It depends on the DID method. A naive solution for uPort is to use an attestation (something like "IDM-Devices") to store an array of the devices. When the DID “did:uport:x” gets setup on a IDM of a new device, this array grows to 1 device. When the same DID gets setup on the IDM of a second device, this array will grow to two devices. Note that during each setup, the user will be prompted to accept the updated attestation. One downside of this strategy is that this array will grow over time and will cost more to update it on ethereum. Another possible solution is to store the list of devices on ipfs instead (encrypted) and the attestion would reference the IPFS hash instead along with the key used for encryption. The costs will then be smaller.

Say they're using uport -- which has an attested DID, is this their root identity and key?

Yes.

How does that get them a list of other devices that they logged in with?

Answered in the first question. Essentially, in case of uPort, diferent IDMs that hold the same DID would request this attestation to get the list of devices.

@joaosantos15 will answer your last question.

[joaosantos15]

Hey, @fritzy, thank you for your comments. You point out some aspects which can be clarified in the RFC, @satazor and I will get to it. Regarding some of your questions,

Are they going to use their ethereum key as their root key?

That would be the case if the user chooses to use an Ethereum based DID (such as ERC-725)

The web3 sign method doesn't work in any gateway that I've tried.

I am not entirely sure I understand the problem. I have used web3.eth sign methods before, usually in the browser, with Metamask, but also in a Nodejs environment using eth-sign-util. In order for the function to work you need to have your Ethereum account unlocked, so you need to call web3.eth.personal.unlockAccount() before calling the sign() function.

If, however, there is another problem with web3 signature methods, maybe you could open an issue on the Web3.js repo, so the team is made aware.

[satazor]

I've updated the RFC where I mistakenly said the the Session Private Keys where generated and stored on applications side. It's now clear the the Session Private Key securely lives in the IdentityManager.