Peer-Star-Identity

[joaosantos15]

Hello,

Myself, @satazor, @pgte and @diasdavid have been working on an identity management application, called Peer-Star-Identity, in the context of Peer-Star (a community developing applications around IPFS).

In recent times, a lot of DID specs have appeared, uPort being one of them. We are focusing on developing an ecosystem which allows any application (centralized or p2p) to seamlessly work with any DID method. It would also allow users to store their identities across multiple devices.

Our problem statement is defined at #16 and an RFC for the identity manager is being discussed at #15.

We would appreciate your feedback, particularly on the issues raised by the problem statement, as you have probably already thought about some of them.

Thank you!

[oed]

Hey @joaosantos15 thanks for reaching out!

Your proposal looks promising, I really like you agnositc approach to DID methods.
The postMessage approach is interesting, we've been thinking along similar lines for improving UX for our users. There is work being done on a did-auth standard within the DIF which might be relevant to you, unfortunately I don't know the details of that. Still very much a WIP I guess.

It might be relevant to be able to, instead of just adding more keys to a DID, create new DIDs for applications and then link these to the main DID. However there isn't really any best practices around that at this point.

As for verifiable claims: The way did:erc725 does it we think is slightly controversal since it puts your claims directly on-chain. While there is no technical problems with this it's likely incompatible with GDPR laws.

We have an experimental DID method called muport which is based on ipfs and minimal blockchain use (for key revokation and updates). Its architecture is designed to be very flexible in terms of keys and data you can add, and what blockchain you use. I think it would work great as a thin identity system for Peer-Star, lmk what you think about it :)

[satazor]

@oed Thanks for your feedback, it's much appreciated.

Your proposal looks promising, I really like you agnositc approach to DID methods.

We are indeed trying to embrace as many DID methods as possible to target as many identities (and users) as possible, while also embracing emerging standards such as Verifiable Claims. Doing so is obviously a challenge but I think we will get there. Our proposal does not attempt to replace any DID method but instead build something on top that will be useful for entities that manage several identities as well as to provide an easy, familiar and safe way for (p2p) DApps to authenticate users.

The postMessage approach is interesting, we've been thinking along similar lines for improving UX for our users. There is work being done on a did-auth standard within the DIF which might be relevant to you, unfortunately I don't know the details of that. Still very much a WIP I guess.

The postMessage idea came like a "oh.. what if.." and it's a very secure way to bridge the communication between DApps and users that control the identities. Regarding the did-auth, we can definitively look into it. It seems transport agnostic, so we could definitively use it. Even if we don't use it initially in case we find it immature, we can later adopt it once it gets finalised.

As for verifiable claims: The way did:erc725 does it we think is slightly controversal since it puts your claims directly on-chain. While there is no technical problems with this it's likely incompatible with GDPR laws.

Indeed, I've been reading the proposal as well as the comments thread. The entities creating identities on did:erc725 need to be aware of that and, ultimately, it's their decision to use it or skip it. Anyway, we will support did:erc725 if it gets widely adopted.

We have an experimental DID method called muport which is based on ipfs and minimal blockchain use (for key revokation and updates). Its architecture is designed to be very flexible in terms of keys and data you can add, and what blockchain you use. I think it would work great as a thin identity system for Peer-Star, lmk what you think about it :)

I will read about it and give feedback! Regarding the revocation, I think it's also a good topic to discuss upon. In my opinion, using the keys that controls the DID often has inherent problems as stated in our problem statement. That's the reason why we introduced layers of keys in our proposal: layer 1 - DID keys, layer 2 - Device Keys, 3 - Session Keys. The DID Keys will then be used sporadically and can be stored safely in several trustworthy places for redundancy. Nevertheless, DID key recovery/replacement is a must in case of a catastrophic event. What are your thoughts on this approach?

Regarding the integration of the uport DID method (or muport), I have a few questions:

1. It seems there's no way to sign arbitrary payload with the DID private key. I couldn't find any documentation on uport-connect about this. For reference, we need to sign Device Public Keys with the DID private key.

2. How do you suggest that we publicly publish the Device Public Keys that were revoked and have them associated with the DID? I've looked into attestations but they are private and selectively disclosed. Additionally, It's not clear if we can add custom properties to the DID document. For reference, we need this to be public because in p2p, peers may need to know if they are interacting with a session associated with a revoked device at any given time.

Thanks for your time!

[satazor]

We have an experimental DID method called muport which is based on ipfs and minimal blockchain use (for key revokation and updates). Its architecture is designed to be very flexible in terms of keys and data you can add, and what blockchain you use. I think it would work great as a thin identity system for Peer-Star, lmk what you think about it :)

Regarding the flexibility in terms of keys and data, are you referring to the publicProfile argument on https://github.com/uport-project/muport-core-js#MuPort.newIdentity and https://github.com/uport-project/muport-core-js#MuPort+updateIdentity? Is that information somehow returned when resolving the did document?

I've looked into both did:ethr (also from uPort) and did:erc725 and they support what we are looking for. The did:ethr supports delegates which can be used as devices. The did:erc725 supports adding action keys of type login and signing which can be associated with devices. Even better, the public keys of delegates / action keys are part of the did document which in turn makes any device compatible with did-auth. Moreover, this simplifies our layered approach, as the layer 2 keys are transparent to verifiers as they are present in the did document.

What's the status of did:ethr? Is it somehow related to muport?

[oed]

I will read about it and give feedback! Regarding the revocation, I think it's also a good topic to discuss upon. In my opinion, using the keys that controls the DID often has inherent problems as stated in our problem statement. That's the reason why we introduced layers of keys in our proposal: layer 1 - DID keys, layer 2 - Device Keys, 3 - Session Keys. The DID Keys will then be used sporadically and can be stored safely in several trustworthy places for redundancy. Nevertheless, DID key recovery/replacement is a must in case of a catastrophic event. What are your thoughts on this approach?

I think this makes sense. We've been thinking along similar lines for having session keys for dapps. And yes, having device keys just makes a lot of sense. In both our main DID methods we have support for a "master" key and then signing keys with less authority. In did:ethr there is an owner and then delegates as you have seen. In did:muport there is a managementKey which is responsible for rotating keys.

1. It seems there's no way to sign arbitrary payload with the DID private key. I couldn't find any documentation on uport-connect about this. For reference, we need to sign Device Public Keys with the DID private key.

You're right, we are currently in progress of adding this to uport-connect. You will be able to request a signature for the DID that is connected. The format of this signature will be a JWTs, take a look at the did-jwt library for reference.

2. How do you suggest that we publicly publish the Device Public Keys that were revoked and have them associated with the DID? I've looked into attestations but they are private and selectively disclosed. Additionally, It's not clear if we can add custom properties to the DID document. For reference, we need this to be public because in p2p, peers may need to know if they are interacting with a session associated with a revoked device at any given time.

This is a tricky one. If your goal is to support muliple DIDs it seems like there is no one way that will work across all of them. For example, DIDs using ethereum it might be easier to publish something in an ethereum based smart contract, for other DIDs other blockchains might fit better. Afaik there is no standard way of doing this kind of thing.

Regarding the flexibility in terms of keys and data, are you referring to the publicProfile argument

Ah, sorry I was refering mostly to the data structure of the DID method. The muport library right now has only a limited amount of features. Support for adding new keys can easily be added though.

Is that information somehow returned when resolving the did document?

Yes it is! It's under a property called uportProfile

What's the status of did:ethr? Is it somehow related to muport?

did:ethr is being integrated into the uport mobile app and will be availiable soon. Delegates should appear in the DID document as well (if not, that's a bug).

ethr and muport are not directly related (other than being DID methods developed by uport). They where both created to facilitate a more scalable identity system, and serve different niches.

[satazor]

Thanks for all the feedback!

This is a tricky one. If your goal is to support muliple DIDs it seems like there is no one way that will work across all of them. For example, DIDs using ethereum it might be easier to publish something in an ethereum based smart contract, for other DIDs other blockchains might fit better. Afaik there is no standard way of doing this kind of thing.

I've came across w3c-ccg/did-spec#63 and it seems the WG wants to standardize on how revoked keys appear in the DID Document. It's a must to have them listed in the DID Document so that they are interoperable across DID methods. We need this list to verify signatures that were made with keys that eventually expired or were manually revoked.

[satazor]

@oed There's other issue that I would to bring on. Our goals in peer-start is to build 99% p2p applications and only resort to a backend as a fallback. Currently, to obtain credentials from uport identities, such as the name or the email, it's required to have a "secret" kept on a backend somewhere.

Of course, the IdentityManager would be able to store a app secret and get "around it" for peer-star apps. Is there any other way to circumvent this?

[oed]

@satazor Yeah, that is a current limitation. Future versions of the connect library will improve upon this, but it isn't a trivial problem to solve, i.e. how do you know that the app is the app it claims to be.

[satazor]

Yeah, that is a current limitation. Future versions of the connect library will improve upon this, but it isn't a trivial problem to solve, i.e. how do you know that the app is the app it claims to be.

Indeed, it's a difficult problem to solve. You could somehow use a similar approach to the one we are doing by using the postMessage API. It provides a secure way to identity apps via the the origin of messages. Though, this just works on some authentication flows. For instance, it doesn't work on a Native Mobile -> Web site interaction.

I would need to think about it for a bit, but indeed it's a hard problem to solve.

[joaosantos15]

@oed and @satazor thank you for your comments! This is turning into a really insightful discussion 🚀

@satazor Yeah, that is a current limitation. Future versions of the connect library will improve upon this, but it isn't a trivial problem to solve, i.e. how do you know that the app is the app it claims to be.

Maybe I'm misunderstanding the problem... In the case of p2p applications such as peer-pad, there isn't so much the concept of speaking to an app, it's more the concept of speaking to a group of nodes who are running the same app as you.

Then, there may be two forms of checking peers' authorization to participate in the application:

• A capability (currently used in peer-pad), such as a shared secret, and in this case you know that any particular node is authorized is it shown knowledge of the shared secret.
• An ACL (to be used in peer-pad), which could contain authorized peers' DIDs, and you would verify a peer's authorization be verifying that it was in control of the DID (maybe using something like DID auth)

Maybe @pgte can offer further insights on this issue. 😄

[oed]

@joaosantos15 The problem we are trying to solve would be something like: Should I (uport mobile app, that controlls the master key) allow this dapp to act on my behalf? i.e. should I allow it to add a key to my DID. I don't want to allow fraudulent dapps to add keys to my DID.

[satazor]

@joaosantos15 The app, being programatic, can take your information and do stuff with it, like storing it publicly and sell your data. Users have to be sure that the information they are disclosing will be delivered to the app they are "seeing". This is tricky to do when the master key doesn't live in the same environment as the app, which is the case in which your master key is stored on your mobile app and you are authenticating in a web browser on your laptop.

@oed The solution I see that would work would be:

• User accesses xxx.com on his laptop and clicks the login button.
• An iframe pointing to zzz.uport.me is created.
• zzz.uport.me creates a unique token for the login attempt, which has the origin associated with it (xxx.com). The origin can be obtained via window.parent.location or via postMessage exchange.
  • This is the keypoint; zzz.uport.me is under uport control and is 100% confident that the origin was not manipulated.
• zzz.uport.me sends the token to xxx.com via postMessage and the QR code (that contains the token) is shown.
• User scans the QR code on the mobile app and is asked to give the requested credentials to xxx.com.
• If the user approves, zzz.uport.me receives the data (via polling or similar) and forwards it to xxx.com via postMessage

Note that this is a very rough description of the flow, let me know if you would like a more detailed explanation. Do you see any issues with this approach?

[oed]

@satazor That's basically the exact same flow as we have discussed internally in uport check here for reference.
The issue I have whith this is the following:

• user wants to access xxx.com but instead types xxz.com which is a malicious domain
• the backend of xxz.com has a fake browser which loads the zzz.uport.me in a fake iframe, but set's origin or window.parent.location to xxx.com
• xxz.com backend get's the token intended for xxx.com and sends it to the frontend which displays the QR-code
• user will think that they access the xxx.com domain as intended since that's whats displayed in the access request
• if the user approves xxz.com get's the data

[satazor]

@oed I really love this geeky discussion!

Correct if I'm wrong but:

xxz.com backend get's the token intended for xxx.com and sends it to the frontend which displays the QR-code

if the user approves xxz.com get's the data

This would be done via zzz.uport.me sending a postMessage to xxx.com which would send a message to tabs at xxx.com. This can't be manipulated because zzz.uport.me is on your control. This means that xyz.com wouldn't receive the token nor user data, even if it tried to fake the whole process.

PS: I don't have access to https://github.com/uport-project/streams/issues/6

[joaosantos15]

@oed @satazor thank you for the clarification.
That being the case, couldn't the user run a hash check on the source code of the app being run on his browser? He could compare the hash with the one published by the app's developer. I'm assuming a p2p scenario, where the user is running his application node locally, not connected to any server.

• xxx.comwould be verified
• xxy.com would not, for it being a modified version

[oed]

@satazor :):):)

This would be done via zzz.uport.me sending a postMessage to xxx.com which would send a message to tabs at xxx.com. This can't be manipulated because zzz.uport.me is on your control. This means that xyz.com wouldn't receive the token nor user data, even if it tried to fake the whole process.

What do you mean by zzz.uport.me being under your control? My point is that it would be loaded by the xxz.com backend, thus me not having control.

[satazor]

@oed Nvm, I read again what you said and I now understand the point you are making. You are absolutely right.

I've been thinking about this and I found a way that (hopefully) is secure, even if the browser is fake or somehow has code injected in any page. I've made a (draft) diagram which explains the strategy, but essentially is a similar flow but with a 2-factor code. Note that the iframe becomes unnecessary.

(sorry for the reflections coming from the windows)

After X wrong attempts to provide the 2-factor code, the attempt expires. This makes it unnecessary to rotate the code each minute. Moreover, the attempt automatically expires after 30m or so or after it was accepted/denied.

The addition of the 2-factor code prevents automated processes that can be faked and the user can reliably compare the request origin with the website he is trying to login. This new flow will only be necessary for p2p applications, where the app secret can't be stored in a secure backend (because there's no backend).

Thoughts?

PS: If you can't understand the diagram I can spend some time doing it digitally.

[satazor]

Bump

[oed]

Hey @satazor, sorry I haven't had time to get to this yet. I'll try to read through and respond to your msg in the next couple of days!

[oed]

Sorry for taking so long to respond!
I think I understand your approach. Basically you add the 2-factor as a way to make the user more aware of the website they are authenticating? This way the user have to check that the urls match. Wouldn't you acheive a similar level of security by querying the user to double check that the urls match?
Maybe I'm misunderstanding something.

[satazor]

@oed correct. We can indeed simplify by warning the user. If the authentication started without the secret, the user is prompted to check the urls before authorizing.

👍

[satazor]

To summarize:

• The secret requirement should be made optional. When not specified, user is prompted to double check the origin.
• Looking forward to ethr DID method, the delegate feature plays nicely with the concept of devices

Thanks for all this discussion so far. I know that uport is already working on the new DID method integration. The optional secret would be really awesome to have as well so that uport plays nicely with p2p apps.