Investigate the appropriateness of Open Badges for what we need

[positonic]

Going through the developer guide, gives instructions for issuing badges as per the Open Badge Specification.

Checking for compatibility - for each Badge there is:

1. An Issuer profile - compatible

2. A BadgeClass - formal description of a single achievement the Issuer recognizes. It includes - name, description, and of course the graphic image, also links to detailed criteria for how the badge may be earned and the Issuer profile that created it. - compatible

3. An Assertion, the record of an individual’s achievement of the badge. Links to one BadgeClass which contains info specific to the Recipient's achievement of the badges critieria:

• date awarded
• encoded recipient identifier
• optional link to evidence
• expiry date

An assertion is the entry point for verification, and i may be delivered either as a hosted object with an accessible url alongside the BadgeClass and Issuer profile resources, or as a cryptographically signed document that the recipient can distribute to consumers.

Initial investigation seems to show good compatibility. I wonder are we, or can we continue to use Badgr to issue Badges via their api.

Otherwise we would need to write something to issue badges, perhaps we can learn from the original Mozilla implementation, which is really looking quite old now at this point, or Badgr server used by Badgr.io - it's in Python.

I would imagine getting the Badgr working would be a good start to see what's involved.

Perhaps we can replace this whole Open Badge spec with something that lives on a blockchain. It would seem that other people have had this idea, but haven't really executed.

There are advantages to the open badge format though, as it should be theoretically be searchable, discoverable, and parsable.

I think we potentially keep the Open badge format and instead link to assertions that are stored in a blockchain, or Digital Ocean (tbd).

Currently, badges reside on the originating badge issuers’ servers, and need to reside there in order for a badge to be verifiable. Perhaps we can create a blockchain based solution.

Badge baking is a very cool concept in Open Badges.

I have also been wondering if we could have some crossover with iden3 claims, which are encrypted and saved on IPFS. They also use zkSNARKs zero proof to protect privacy and validate claims.... hmmm

This is an example of a badge issued by Badgr
We need to have a page like that on our website.

Use case for a issuing of a badge:

1. Someone contributes money or time to an NGO and as the NGO I want to be able to issue a badge to that person.

• Issuer - The NGO
• BadgeClass - What contribution is being acknowledged
• Assertion:
  • id
  • type - 'assertion'
  • receipient - IdentityObject - most commonly email, but can also be [telephone / url](https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#ProfileIdentifierProperties or maybe wallet address?
  • verificationObject -

A collection of information allowing an inspector to verify an Assertion. This is used as part of verification instructions in each Assertion but also as an instruction set in an issuer’s Profile to describe verification instructions for Assertions the issuer awards.

HostedVerification and SignedVerification are subclasses of VerificationObject. Future subclasses may be developed to indicate instructions for verifying Assertions using different methods, such as blockchain-based

We are hover only talking about verification that a donor or volunteer did something. Let's say a donor donated money to an NGO. So the proof could be a link to the blockchain transaction, then the donor would only need to prove their address and verification is assured.

This only applies to Crypto-transactions though but perhaps that's a place to start.

2. (In the future we may potentially) A company or NGO acts in such a way that we want to be able to issue a badge to them.

[positonic]

After deep-dive into open badge, I see that the purpose is:
Someone has to issue the badge AND host the badge. Or at least the evidence of the badge. The badge consists of:

1. An issuer
2. The achievement (or what the badge is for)
3. The assertion - the connection between the badge and the person who it's awarded to.

All of this needs to be hosted by somebody (a badge issuer). We were looking at Badgr (replaced Mozilla backpack) for example. In order to do this, we would need to be that issuer. So we would need to host our own app for issuing and hosting badges.

We would need to do this because I think we should modify the protocol slightly to make the evidence blockchain based.

One thing that is appealing about Open Badge rather than a blockchain based solution is that isn't only for blockchain based people and the need for a wallet. I thought he same, until I realised what Open Badges really are - it's all about the validation of the badge. So you can point an app that is designed to understand the open badge format at the badge, and it can automatically validate the authenticity of the badge. It can see that there is an issuer and it can verify that the issuer can be trusted. It can check that there is evidence connected (which is very weak as far as I can see, as evidence basically amounts to a URL. - which could be anything - there's no parsing of the evidence url, it could be a web pages with a photo, or a smiley face even). So the validation process relies heavily on the fact that the issuer is a confirmed "cool guy", that is all. Ultimately who has even got / and use and app that verifies a badge? Not many.

Clicking on a badge issued by Artur to us goes here - https://badgr.io/public/assertions/0FABs3SySECMorVX5ebTlg?action=download

This is all the open badge is.

We could build a similar page, except that in the background we go to the blockchain and verify that the person actually donated money to an NGO via the blockchain. We need a confirmed address of the NGO and confirmed address of the person we're issuing the badge to, and we have something WAAAYYYY for powerful and way more independently verifiable and even easier to use, as we can have an app / wallet that does that, automatically.

[positonic]

it's nearly the same except that we don't need Open Badges - as Open Badges are insufficient for what we want to do
Our innovation is all about how connect to the evidence on the blockchain
the weakness is that this only works for crypto transactions

Validation:

Landing on our badge assertion page we will have verified the identity of the Receiver of a donation (tbd - how), and the donor. We will parse the transaction on the blockchain and identify how much was donated.

If we connect and co-operate with Giveth we can also track what that money was used for, and what sort of projects the NGOs are involved with.

The role of the badge assertion page is to interpret and understand the transaction on the blockchain and present it visually to the user. This same role could be interpreted by any application (mobile / dapp etc) that understands the underlying protocol. This protocol will need to be defined. Should this be some sort of ERC standard? There is already a proposal for a non-transferable token - but it is focused on education as the Open Badges specification is, and I think we need to go one step further, as the real magic for us is around the establishment of a relationship between 2 parties and the verification and validation of transactions that realise that relationship into something that requires a badge.

A token (or badge) can be issue whenever a connection is made between 2 separate wallet addresses (donor and receiver), and then the data in that badge (relationship) is then updated any time a transaction is made between them.

Another thing to keep in mind is (and we discussed this before), is a badge a relationship that changes or is each donation a relationship? I lean towards the first option.

As I said before, I'm also in favour badges for NGOs (organisations / companies) at some point in the future.... first things first.

[positonic]

A preliminary skeleton solution:

1. Some method of onboarding NGOs that involves them proving an address to be theirs. We have a similar process for onboarding donor addresses.
2. We have a worker that listens to all ethereum blockchain events, checking each transactions 'to' address, and check it against monitored addresses.
3. If a deposit is detected, we generate a badge (somehow?) and email the donor of the depositing address.

[positonic]

I think a core decision is if we issue a badge per transaction (Payment) or per relationship (between donar and NGO) - as this would dictate whether an extended non transferable ERC-20 (cheaper) or an extended non transferable ERC-721 that can be modified with as more payments etc are made (is more suitable). - I think this is a core decision for any tokenised part.

The existing 721 standard allows for meta data about the token which is used to include a url to the image stored off chain. Owners of the badge can use this url to display their badge off chain visually.