The issue that you are adressing about your open badge being transportable , is a recognasible issue and in my eyes maybe even essential for the succes of the Open Badges format.
I will try to explain my view on this.
This is maybe a personal view, but at this moment it reflects the view of the project team and network who we are building a Belgian Badge platform with.
We are facing the same issues that Mark of Pearson's Acclaim describes.
Trust is an important factor for our network and stakeholders that are involved in this. This was even the main reason for us to decide to build a platform of our own.
Being a governmental organisation, there are even other aspects to that than the ones Mark describes.
Thus, although I differed personally from opinion, we decided to build a platform of our own (in stead of building together/further on others).
This for me raises another issue, with us building 'yet another platform'.
Are all of these platforms competitors to eachother ("trying to get the likes and badges of the most earners/issuers") or are they part of the same goal to "Badge the world" and build a big ecosystem of Open Badges?
Well if I look at the current state of the Badge Ecosystem, all of the platforms (Acclaim, Credly, OpenBadgefactory/OpenBadgespassport, Bestr, Badgr,...) they are all doing (maybe with different approach and to a different extent) great efforts for working together on that same goal.
They all add with their individual approach and effort to the wider spreading of the format of Badges.
Are they all perfectly interconnected? No, they are not (yet). Most of them are even very proprietary about their information and data (for which good reasons can exist)
Do they need to be perfectly interconnected? Well, I don't know but would like to cite some words of Chris McAvoy back in 2012: "We need a system for making all the backpacks in the world act like one giant backpack for the purposes of aggregation and discovery. This is a tricky one, but it will be super awesome when we’re done with it. Super awesome."
How do we in Belgium are planning to tackle the problem between building the trusted badge network (like Mark mentions) and being fully transportable (like Charles questions):
From a UI perspective we will have a webadress on which earners and issuers will have all the functionalities they need to build a trusted Badge network.
Like Pearson's Acclaim, both issuers and earners (and also the broader (Belgian) Job Market) will know that when seeing/earning/issuing badges on that webadress, they are verified by us.
We have a level of 'control' on the badges that are coming from, or are imported in our platform as long as they are in our platform. So we can give trust levels to them, needed for our network to be able to adapt a system of Badges.
(in a way comparable of the needs of Acclaim and the clients they work with)
So from an UI perspective we are also building our platform like this.
Both issuers as earners, are encouraged to use our platform and UI to create and store their badges.
And if they share them with others, we will encourage them to use public links (like the one from Acclaim that you posted Charles) or share them on Social Media (FB, Twitter LinkedIn) via our platform.
But that doesn't make the badge transportable yet.
Transportable is when you can take the badge out of our platform and put it in another platform (or just store it locally since the metadata is embedded in the file)
For us this is about ownership of data.
In our philosophy the ownership of the badge (and the data linked to it) is a sort of shared ownership of the issuer, earner and platform it resides in.
Let me compare it with what Facebook does:
if you put a picture on Facebook, it still is your picture, but as long as it is on Facebook, there are things in Facebook's disclaimer that you should know about because it is maybe no longer only your picture.
You shared the ownership of the picture in a way with Facebook.
I believe that (even if it was Facebook itself that helped you create that picture of yourself), the individual always should have at least an equally control over his/her data as the organisation he/she choose to share his/her data with.
(don't want to open a discussion on that one, but I guess everyone is aware of the fact that people don't read disclaimers and sometimes give organisations more control over their data as they would have liked to)
To get back to our Badge platform:
although it can give issues of reducing trust in our badges (because we loose 'control' over them), we will allow our earners to both import and export badges in and out of our platform.
(as also is integrated in the Mozilla Open Badge Backpack itself)
We haven't decided yet in what way we will interconnect with other 'backpacks' (via API's that exists) , but in any way, earners can download their badges with the metadata baked in, and like such they will be transportable to any platform that follows the OB standard and specifications.
I agree fully with Mark that this can bring an issue of trust and I fully understand the decision of Pearson in this.
But in-between solutions that we want to bring to the Belgian Job Market to tackle this, are:
- bringing the verification process to the organisations self that are 'accepting' badges. (via API they can check if a Badge is valid , at the very moment that they want to 'validate' the badge in their process e.g. in a hiring process, a badge verification is included just before the interview phase)
- giving different 'values' to badges that are inside or outside of our platform. This can be the same badge, that is a 'trusted' badge when residing on our platform (on our URL), but we don't give the same trust to that same badge when it is not residing in our platform.
Would like to hear the remarks of the community on these 2 possible solutions.. because I guess these are also not without any problems.
But for us ,being able to import/export the badge , is essential to an ecosystem of Open Badges.
Giving this control of the data to the earnes is in my eyes one the big strengths of Open Badges, compared with a system that uses plane certificate repositories with unique id, like e.g. Coursera does: https://www.coursera.org/signature/
Because what does Open Badges add to such certificate repositories:
- it brings standardisation to the format of constructing those certificates
- it brings interconnectability (and transportability) to them by the use of machine readable JSON-LD and API
To end this post (that has become longer than I planned to) I would like to give a link to a superb blogpost of Chris McAvoy, that gives a more broader view on the issue of transportability than mine which needs to take limitations of our local implementation into account (that blogpost also explains me mentioning Facebook here ;-) ):