The problem Identity Management ETHIndia solves

Imagine we want to deploy a Listing contract to sell a Airplane ticket, but only allow interactions from users with a verified email address. How can we accomplish this with ERC 725?

First, lets define the entities that will be interacting:

The Consumer is an identity who wants to buy the ticket.
The Issuer is an identity which issues claims of type 'EMAIL_VERIFIED' & 'PHONE_VERIFIED'.
The Listing will only allow Consumers with an EMAIL_VERIFIED & PHONE_VERIFIED claim from an Issuer they trust.
This leaves us with a few questions...

How does the trusted Issuer verify an email address?
How does the Consumer get an EMAIL_VERIFIED & PHONE_VERIFIED claim onto their Identity?
How can the Listing verify that the Consumer has an EMAIL_VERIFIED & PHONE_VERIFIED claim from a trusted Issuer?
To answer these questions, lets go through the process of setting up all the required contracts and services, starting with the Issuer.

The job of the Issuer is to act as a trusted third party. In the future, trusted organizations may deploy their own Issuer identity contracts onto the blockchain, which third parties can then trust. Origin plan to offer their own basic Issuer contracts for verifying email addresses, phone numbers, Facebook accounts, Twitter accounts, etc. Third parties will then be able to trust that these Origin Issuer contracts only issue claims if they are, in fact, true.

How will an email verifier work? A typical verification service may involve an application, fThis application will have a standard interface for verifying an email address, whereby a user is sent an email with a special code which they then submit back to the application. Now that the email address has been verified, it can be signed with a private key known only to the email verifier app. The corresponding public key is on the issuer's identity. This is how a claim is verified.

Challenges I ran into

authorizing authority
wallet inbrowser