We are seeking developers to create an app where users can request any 3 education credentials  from other users. Any user can request a presentation over 1 or more credentials. The credential data is mostly hardcoded and the only changing part will be the DIDs of the holder and issuers and thus the public keys and signatures. The functional requirements below contain implementation suggestions assuming a demo-quality app but better alternatives can be used if time permits.



# Functional requirements



- The credential data should be realistic. Don't use data items like foo, bar or blah.

- Users should have a DID on the  testnet.

- User should be able to store his/her DID, public and private keys in the app.

- Users should be able to send messages (probably JSON) to each other. A simple implementation where each user registers with their DID to the trusted server ( and then sends messages to that server for another user's DID is acceptable. You can assume users learn each other's DID out of band like through email, sms or verbal communication.

- A user should be able to request 1 of the 3 credentials (each credential has a unique id) from a connected user. Assume that all users can issue all 3 credentials and request format can be JSON.

- The credential recipient shows a message on receiving credential and stores the credential (each credential can be a JSON file and naming each file as . is fine)

- User should be able to request presentations from other users containing one or more credentials and issuer by certain DID. Assume that users only request for presentation for which the responder has credentials. The request format can be JSON.

- The presentation recipient shows a message on receiving a presentation but does not store it.



# Technical requirements



- The app must run in browser

- Our SDK must be used.

- The SDK must be used against the deployed testnet.

- In a browser, local storage and be used. Ignore the problem of secure storage and store all private key in the same place as other data in the interest of time.

- The communications need not be encrypted beyond HTTPS.



# Bonus items



- We would appreciate if bugs in our code are reported.

- We would appreciate if improvements in our tutorials or new tutorials are suggested.

- Suggestions to improve our API are welcome.