Identity and common identity interfaces

We've all heard about the famed 'identity' contract, but relatively little has been said about its specifics.

Lets Brainstorm

I think it would be beneficial to brainstorm a bit about abstractly what 'identities' represent, what functions we see 'identities' fulfilling, and try to gather the sorts of interfaces that will be used. Any common language we come up with can provide us with a more discuss-able topic. (Currently, talking about this topic feels like word soup, a lot of abstract, overloaded words mashed together that don't mean much.) Further, if we can coordinate on what exactly an 'identity' entails, this will provide some sort of foundation for the v1 ecosystem of dapps seeking to interact with people. We'll want to be able to have reusable identities in some situations, and this requires some minimal sort of interface standardization.

I'll start off with some thoughts to get us started.

What is an Identity?

So there are many definitions of identity. Wikipedia, alone, has 30+ different pages on the topic. (For our purposes, I recommend starting with Entity, Persona, Digital Identity, and Identity 3.0)

Lets start with some definitions which might be useful (taken and tweaked from here (last page of document)):

Attribute - An observable property of an entity.
Credential - Immutable combination of Verified Identifier and Verified Attributes.
Entity - Any person, organization, computing device, code, data, or physical possession; also any self-managed collection or organization of entities.
Identity - Synonymous with persona.
Identifier - An attribute of a persona which identifies it, with sufficient uniqueness and immutability, that its trustworthiness can be assessed in a known context.
Persona - A user-centric term. An entity uses a persona to represent an aspect of itself (such as parent or employee and client or a server) through a collection of attributes, in any interactive situation.
Verified Attribute - An Attribute that has been assigned to an entity by a trusted third party.
Verified Identifier - An Identifier that has been linked to an entity by a trusted third party.

I'd like to focus on a form of identity I'd like to call persona, or weak identity. This form of identity does not attempt to fully model the relationships that a human has to the world, or create a one-human-one-identity system. This is a user-centric approach to identity, upon which stronger forms of identity can optionally be formed. This means that personas are constructed and tailored to user-defined needs from a user-defined point-of-view.

What is an Entity?

An Entity, in the context of Ethereum, is a point of (cryptographic) control. The simplest form of this is an Ethereum address. The address is a point of cryptographic control in that it provides a permission-restricted means of arbitrary data and token transaction, ie, it can create data transactions and send/receive ether. So any contract hoping to implement an entity in Ethereum would include some way to send some sort of transactions and/or send ether. Since this includes any non-trivial contract, lets differentiate this with a free entity, a special case of entity, which can send arbitrary transactions and ether sums, in other words, have the full range of possibilities that a normal Ethereum address allows. To further differentiate between the transaction sending and ether sending, lets call an arbitrary transaction sender a txsender, and the arbitrary ether sender, an ethsender. So a free entity is both a txsender and an ethsender.

What is a Persona?

A persona, in the context of Ethereum, is an entity with verifiably linked attributes.

My personal intuition surrounding this is: a social identity typically has dual components: a self-identity -- an internally-agreed-upon role or definition, and an externally-dictated identity -- the identity as defined by other identities, often as interpretation of the self-identity. Attributes are just the simplest ways of representing these internal and external definitions in a structured way.

Keeping with the user-centric approach to personas, I posit that attributes cannot be dictated by the external world upon a persona, within a persona; the external world can merely tack on verifications/attestations to existing attributes. Any undefined attributes to be linked to a persona by an outside identity would be done elsewhere (not explicitly part of the persona).

My version of an attribute list would look like a user-defined attribute list with attest-able attributes. These attestations are strings linked to other identities, to be interpreted by other applications. In other words, verified attributes would simply be attributes attested to by trusted personas. Verified identifiers would be uniquely-given attestations of a specific attribute by a trusted persona (possibly stored in a more indexable fashion on-chain, as well).

So simply, a persona is an entity and a attribute list.

What about the name?

Names, in this context, are usually used as identifiers for personas. Since personas exist from a user-centric viewpoint, names as identifiers do not necessarily make sense within a persona, since there is no guarantee of unambiguity between persona namespaces. I expect that various name-contracts, with differing properties, will allow for pseudo-global names. Perhaps, in some namespaces, names are immutable once set. Others will go as far as providing markets for trading names. Of course, the original immutable name is the contract address.

So what is an identity contract?

In its simplest form, I think an identity contract is simply a persona, as defined above. For general-purpose identities, they would probably be free entities, as well.

In Solidity, this could look like:
contract Identity is txsender, ethsender, attributelist, ... {
...
}
(I'd probably want some sort of multi-sig/group-membership for important identities, among other things, too.)

Sample brainstorm questions

Which things ring true to you? false?
What does an identity contract mean to you?
What does a persona contract need to do in your application?
Where is the missing functionality?
What do each of these interfaces actually look like?

Comments

  • rabbitrabbit Posts: 15Member ✭✭
    Excellent breakdown! Here's a quick contribution.

    I believe an attribute list on its own is a lousy identity language for humans. We don't relate to identity strictly in terms of state, if anything it's closer to precedence and inference which has more to do with expressions being interpreted over time. I would recommend thinking of a persona as a resource that emits assertions or claims about itself and the external world. Implemented as an attribute list, it's pretty flat and will exhibit the same rigid behavior as state, but as a history of interpreted statements you can build experiences that more closely mimic what we expect.

    The "identity contract" (as a concept) should be thin and dumb. It should provide a mechanism for "reading" an identity to produce a canonical form. Different identity systems and relying parties can innovate internally and interoperate through the canonical form. So an identity contract might be super simple (just the "reading" part) or super complex (time delays on sensitive operations, merging data from multiple domains) so long as they both implement compatible reads. The write aspect of identity is contextual and would come after a read step to determine write capabilities. Approaching this in layers also makes it easier to adapt between on and off chain.

    I've been awake 18 hours and I'm sick so if any of this made sense I'll be amazed.
  • wemeetagainwemeetagain Posts: 30Member
    rabbit said:

    I believe an attribute list on its own is a lousy identity language for humans. ... Implemented as an attribute list, it's pretty flat and will exhibit the same rigid behavior as state, but as a history of interpreted statements you can build experiences that more closely mimic what we expect.

    Absolutely. One of the primary forms of 'attributes' I see is a link, to either a separate ethereum contract, with its own rules, or some off-chain content, in the form of a content hash (think IPFS or otherwise). In any case, a default identity contract will probably log all changes to attributes and attestations.
    rabbit said:

    The "identity contract" (as a concept) should be thin and dumb. It should provide a mechanism for "reading" an identity to produce a canonical form. Different identity systems and relying parties can innovate internally and interoperate through the canonical form. So an identity contract might be super simple (just the "reading" part) or super complex (time delays on sensitive operations, merging data from multiple domains) so long as they both implement compatible reads.

    Yeah, this is the reason why it is beneficial to hash out (pun intended, lol) the interfaces of an identity contract. We want to come to a 'common' definition about what a contract does, regardless of how it does it, so that any conforming identity contracts will suit any applications that interact with an 'identity', as much as possible.

    As an example, I had briefly mentioned multi-address-controlled/"multi-sig" identities. In this situation, some sort of permission system governing shared control of the identity (among addresses) would need to be implemented. This should not effect how the identity interacts with the outside world.

    You mention time delays, as in time-delayed wallets that only transfer certain token amounts per timecycle, as another great example.
    rabbit said:

    I've been awake 18 hours and I'm sick so if any of this made sense I'll be amazed.

    made sense to me :+1: :smiley:

  • wemeetagainwemeetagain Posts: 30Member
    https://github.com/tradle/about/wiki/Identity

    This is a great document! It covers some similar elements as the OP, but in a much more concrete way, primarily looking at storing PGP keys as attributes.

  • wemeetagainwemeetagain Posts: 30Member
    edited April 2015
    Finally got around to writing some code.

    https://github.com/WeMeetAgain/eth-id

    Tests? who needs tests for something as important as your entire freaking identity. /s

    I haven't tested any of this stuff out, and I'll be writing some tests and enhancing this stuff, but it mirrors some of the ideas above. It is an `Entity`, which allows for arbitrary contract calls to come from it, `AttributeList`, which is a kv mapping with optional 'links' to other addresses, and a `VotingGroup`, which lets the whole thing act like a multisig wallet.

    To be clear as to how it could be used here are some scenarios:

    I need to authenticate for a dapp, it requires the user to send a transaction with some data -- Using my identity contract, I can coordinate my member addresses (hopefully stored in disparate locations) to each send a transaction to the identity address specifying the dapp address and the required data.

    A malicious actor stole my phone with an authenticated address/private key which has access to my identity: Using the identity contract, I can revoke the membership of that compromised address by voting with my other addresses to `removeMember` that compromised address.

    I want to store public identity information in one consolidated place: Using the identity contract, I can store useful identity data, like email, pgp key, etc, in its attribute list, under a descriptive name. Alternatively, I can put a 'link' to another authenticated datastore in the blockchain rather than the full, posssibly large data, all in the blockchain. This link could be to IPFS, swarm, etc.

    I want my identity to reflect some real world relationship on the chain: Using the attribute list in the identity contract, I can have other entities link attestations to certain attributes. This creates a sort of web of trust.
    Post edited by wemeetagain on
  • aatkinaatkin Posts: 75Member ✭✭
    Nice work! I'll let you know if I get anywhere with ipns + Eris.
  • oliverkxoliverkx Posts: 85Member
    Sorry for the newbie question - but how would such an identity contract work in practice, particularly if used for the purpose of authentication for an off-chain application?

    For instance, let's imagine that some group of regular (non-Ethereum) applications wanted to use a common authentication scheme. They could go with MS-Live, Facebook, etc. Or, could they go with an Ethereum contract?

    If a user wanted to create a session Id, by submitting a login and password to the contract, how long would it take for the session Id to be returned? Immediate? One block (12 seconds)? Several blocks?

    Same question for the application that wanted to validate the session Id for a web request. How long would it take for the Ethereum network to return that validation result?

    I love the power and flexibility that Ethereum promises in this area, with some of the examples already listed above (e.g. ability to revoke a membership, web of trust, etc.). But could Ethereum be used directly as the back-end for such an authentication scheme, or would it be too slow for the kind of real-world scenarios I mentioned?
  • pkolarovpkolarov Posts: 2Member
    @oliverkx
    oliverkx said:

    Sorry for the newbie question - but how would such an identity contract work in practice, particularly if used for the purpose of authentication for an off-chain application?
    For instance, let's imagine that some group of regular (non-Ethereum) applications wanted to use a common authentication scheme. They could go with MS-Live, Facebook, etc. Or, could they go with an Ethereum contract?

    In order to do this you would have to build a proxy service (AFAIK) that would look like e.g .OpenID Connect on one side and send messages to smart contracts on the other side. This would however make a central point (SPOF) and is not ideal but it is still way better then any one central identity provider such as Google or Facebook.
    oliverkx said:


    If a user wanted to create a session Id, by submitting a login and password to the contract, how long would it take for the session Id to be returned? Immediate? One block (12 seconds)? Several blocks?

    You dont want to probably send username/password to public block chain, you would send data signed by your private key (e.g. one stored in your browser or even better in a dedicated HW token) to access your account which in turn would access your attributes and provide them per your request to the relying party/service.
    The timing is dependent on the ethereum network state - I think you can figure out the aproximate response time from their dashboard somehow?


  • oliverkxoliverkx Posts: 85Member
    Thank you for the response! I guess part of it went a bit over my head, but it still helps me trying to build an overall picture.

    One thing that I had imagined was that the state of a user account (e.g. a user's group memberships or access permissions) would be accessible in clear text in the block-chain, or would it? If so, once the session was authenticated and mapped to a user, the software could just read the block-chain directly from local storage, and not incur the delay and cost (in ether) of executing a contract method in order to obtain that information.

    But overall, a block-chain-based authentication scheme would use-up ether every time a user authenticates, or any account information is updated, correct? Not that that's a bad thing - just confirming my assumptions...

    Thanks again!
  • pkolarovpkolarov Posts: 2Member
    @oliverkx
    oliverkx said:

    Thank you for the response! I guess part of it went a bit over my head, but it still helps me trying to build an overall picture.

    Well, I am also trying to figure out the details of how such an identity provider would exactly work, so thanks for making me think about it in writing.
    oliverkx said:


    One thing that I had imagined was that the state of a user account (e.g. a user's group memberships or access permissions) would be accessible in clear text in the block-chain, or would it? If so, once the session was authenticated and mapped to a user, the software could just read the block-chain directly from local storage, and not incur the delay and cost (in ether) of executing a contract method in order to obtain that information.

    Yes, this is a good idea to save ether and some latency, but I would not go as far as plain text, rather both relying party (RP) and identity provider (IDP) would store a hashes of those authorization and identity attributes in the blockchain while the entity would make a claim to those attributes by knowing the clear text and some nonce/salt locally. The block chain would then serve as a proof that they were assigned/revoked those attributes at a given time.
    oliverkx said:


    But overall, a block-chain-based authentication scheme would use-up ether every time a user authenticates, or any account information is updated, correct? Not that that's a bad thing - just confirming my assumptions...

    Yes, thats ok, I think it would be paid by the relying party as an initiator of the transaction, while entity would co-sign the multisig contract to prove it has one of the private keys in the wallet.

    Really, I should try to make some code to test this, may be starting with the contract above @wemeetagain has proposed.

    -peter
  • AjoyBhatiaAjoyBhatia Posts: 7Member
    Reactivating this after 2 years... :)

    My question is: If Identity is defined as a contract, then how is it deployed when an Entity is created for the first time?
  • qqwyqqwy Posts: 15Member
    I would like to leave my two cents here.

    In Februari, I was part of the 'EpicAuth' team at the Dutch Blockchain hackathon. We had a wonderful idea which we worked out to a great Proof-of-concept during the hackathon. In the end, we did not continue with it because the chance of it getting traction in the real world is very low, as all three parties involved with identification/authentication need to swap to EpicAuth at the same time (users, Identification Providers, Identification Consumers).

    The idea there was to allow users to request Identification Providers to sign independent attributes and identifiers for them. These signed attribute documents are not stored in the blockchain, but the user stores them themselves. The do however contain a reference to a location on the Ethereum blockchain, which an Identification Provider can alter at any time to invalidate the signed attribute document.

    An Identification Consumer can then ask a user for a set of signed attribute documents, where each Identification Consumer can define their own set of Identification Providers they trust for certain kinds of attributes. Users can then in a user interface (such as a browser extension) select which attributes are they want to use (because it might be possible that certain attributes have been verified by multiple providers, or that the user has multiple e-mail addresses, phone numbers, etc. to pick from).

    The Identification Consumer can then at any time check if the attribute still is valid, and because this part is stored on the blockchain, it is independent of the availability of the Identification Provider.

    On paper, this works great, but the problem is then moved to one of building a proper Public Key Infrastructure. And changing everyone at once to the new system is probably an impossible task.

    In any case, maybe this inspires someone in some way :-).

    ~Qqwy/Wiebe-Marten
Sign In or Register to comment.