Identity and signing key - architectural update about firefly HOT 10 CLOSED

The matrix helps a lot!

Fabric doesn't really have an anonymous equivalent to an HD Wallet based signing key, because since it's x509 certificate based, the CA's identity must always be disclosed, which gives away the org identity it belongs to. Fabric doesn't allow a signer certificate that is issued by an unknown authority to interact with a channel.

I think this means with Fabric, private messages must either be unpinned, or be pinned with a known identity. whether the pinning identity is registered with the network map or not, does not change the fact that its identity can be verified and associated with a member org based on the cert itself.

from firefly.

This is a great point.
Maybe next step is at a database/entity level, is to sketch out what information would be stored by FireFly in a 2 object, vs. 3 object model.

I guess in my mind to date, an organization in the Firefly is one possible type of identity. A node always felt like another type. Then on the horizon is something like a person (self-sovereign identity) / thing (IoT etc.) as another type. To your point that's probably incorrect thinking.

I'm hoping I can find a mechanical step forwards by introducing an Identity Manager component (distinct from a plug point), that helps with the mechanics of getting all this logic in one place in the code.

Then if we need to evolve the concept of identity a bit, at least it's a self-contained task with minimal side effects.

from firefly.

A few of us had a whiteboarding session, and the outcome was this beautiful wall of noise... and the conclusions below it:

• We need to split Author into two fields - one representing identity, and one representing signing key
• We need to split Key as a different object to Org and allow multiple keys
• We need a consistent URI scheme for signing Keys
• We need to update the Identity Interface [Ii] before it can be useful for plugging in DID resolution
• We need a separate plug point for Blockchain plugin+connector stacks (ethconnect/fabconnect) to resolve input strings, to key URIs
• We need to create a matrix of how input identity, maps to the stored Message objects, and what verification is performed

from firefly.

Here is first attempt at the matrix, for @jimthematrix to review as he works on the other items.

firefly_message_identity_matrix_20210907.pdf

from firefly.

I wonder if we actually have 3 levels of identity objects: Org =1--*=> Identity =1--*=> Key

An org can have multiple registered signing identities. A signing identity can have multiple signing keys (as a result of key rotation, or an identity having a primary key and a backup key for recovery). I know we talked about some of this, but don't know if your model above was deliberately collapsing signing keys with signing identities.

from firefly.

The thing on Fabric I'd read about was: https://hyperledger-fabric.readthedocs.io/en/release-1.2/idemix.html
However, 99% case certainly feels like having a channel scoped to a set of verifiers where disclosing transaction submitters is considered low-risk metadata leakage. But probably a conversation for other threads and issues.

from firefly.

@nguyer and I have been working on #192, which is intending to get the engineering started on implementing the split of author and key.

In doing this work, we will be carving out a place in the code that a governance plug point should exist and does not today:

When adding a new root org to the network, it should be possible for plugins to provide external verification that this member is authorized to create a new root identity.

from firefly.

Quick slide pulled together to aid the community discussion on 9/29

firefly_discussion_identity_20210929.pptx

from firefly.

This thread has great points to ponder upon. However, I see blockchain pinning of transactions and anonymous signature verification are stressed throughout in designing the solution. Idemix in Fabric attempts to dissolve an identity's authorized attributes but does less on anonymizing the issuer's identity. I had a different thought altogether about identity management at the connectors. But before that, it make sense to understand the current identity model in FireFly, could you please point me to more information?

from firefly.

Closed in favor of further discussion and feedback in the FIR hyperledger/firefly-fir#9

from firefly.