Permissions based on identity and new identity providers

[zachferland]

May be misunderstanding new identity providers, but it seem like the permissions, specifically write permission in this example should be based on the identity id and then use the identity provider to verify. Orbitdb keys are provisioned upon use and in different systems identities may be used across differing contexts (or have revocation, rotations, etc) where there will be different local orbitdb keys for signing (for same id). So seems like permissions would be based on identity id not the orbitdb pubkey. ( i saw the orbit identity provider where these are one and the same). And why verify identity in orbitdb AC if not using that identity for access control.

This code was just for context and explanation, not tested yet. Two changes, one, used identity.id for permissions, and then in ipfs access controller if using identity.id, also verify identity.

If the explanation above was intended functionality I can finish creating and testing this PR.

[shamb0t]

Thanks for the PR @zachferland! Write permissions depend on which key is added to the 'write' list. The reason the public key is used is it is assumed to be a master key (which signs 'identity.id') and access is checked against the master (public key). However a custom access controller which checks against the id is also possible (here the id is what should be granted access and in that case the identity should be verified to link the id with publicKey since it is the public key which signs entries). Does this help? You're right that the identity needs to be verified if id is used. Are you using an external id in your use-case?

[zachferland]

thanks @shamb0t! yeah, I follow, and we can definitely make a custom access controller, but i guess I don't understand why it is the default (identity.publicKey) still with the new identity providers.

I guess i would only assume the identity.publicKey to be the master key if I was using the 'OrbitDBIdentityProvider', but in this case the identity provider would denote that, and then identity.id/publickey would be same, and it would still hold the same if using the 'identity.id' still. Then this would support custom and default.

Also without using identity.id for defaults, then you don't get any use out of using custom identity provider with default access controller. For any custom identity provider, we would have to create a custom access controller.

Yeah, ill give some more context for our use case. We do have an external id, and external key management for 3box. So we will have a our own identity provider, and would also like to create a general DID identity provider. Our keys are derived from ethereum accounts, and many other keys for stores are derived as part of an HD tree (all of which are also DIDs). This means the same keys will be derived in different contexts or different orbitdb environments, simplest example is orbitdb loaded in differing apps/domains.

So in that case, the thinking is orbitdb keys are more ephemeral, provisioned upon use and can be lost (localstorage cleared). Users would have the same 3box id across those environments but would have a different orbitdb signing key in each.

This then keeps the nice abstraction your identity provider has created, and the separation. Where we don't have worry about oribitdb keys (or the keystore, signing, etc), and can keep our id/key model entirely separate, with the ability to always link in to orbitdb through this thin interface.

[shamb0t]

@zachferland fair point that it may be more useful to have a default ipfs-access-controller use the external id...we used the public key in old access controllers but I think it makes more sense to create a legacy controller for that and use entry.identity.id for the default controller