Endorsement 'of' a badge / Endorsement 'for' a badge

[Serge Ravet]

The latest confcall triggered the following reflection: with our current view of an endorsement assertion linking a badge class to an issuer (which is right), isn't the message we convey: "I trust this issuer to deliver that badge?"  Then how about the assertion I trust this issuer to deliver badges of a certain type" (a meta-class), or even "I trust this issuer to deliver badges in their domain of expertise?" There are also accreditation bodies like AACSB for business schools or ABET the Accreditation Board for Engineering and Technology that are in fact providing this kind of 'endorsement.'

I perceive the issue we are addressing (badge-issuer endorsement) as a particular instance of a more general one, usually referred to as accreditation. If it is true, then there might be an advantage at addressing the more general issue, instead of a particular instance. Generalising the 'badge-issuer endorsement' into a more general problem could help us find a more general solution.

Making a parallel with the expressions 'assessment *of* learning' and 'assessment *for* learning, I wondered whether it might be relevant to distinguish between 'endorsement *of* badges' and 'endorsement *for* badges.' What would the difference be?

My interpretation of 'endorsement for badges' is a trust relationship between an endorser/accreditation body and an issuer that can make direct references to specific badge-classes or groups of badge-classes or to general qualities of the issuer that are relevant to the issuing of badges. Having the AACSB, although not making reference to a specific badge, in would recognise the ability of the accredited organisation to deliver a "management Level 4 badge." The organisation is 'endorsed' to deliver a whole range of qualifications and certificates that can take the shape of badges.

Just my two pennies :-)

[Nate Otto]

For reference, Deb brought this up in response to my post to the BA-Standard Working Group, where I speculated:

The way I've been thinking about it, we have three basic badge objects in JSON: the Assertion, the Badge Class, and the Issuer.

And how we've been thinking about how they relate to each other is that for each Assertion, there must be a Badge Class, and for each Badge Class, there must be an issuer. These are declared in the Assertion's 'badge' property, and the Badge Class's 'issuer' property.

Each Issuer may have many Badge Classes, and each Badge Class may be issued many times (have many Assertions). These relationships aren't declared in the metadata, though Kerri has proposed linking a 'badgelist' from the Issuer definition to help make it clear to potential earners what their opportunities might be (probably through products like the Directory).

Here's all that in picture form:

See how the Has 1 links are defined in each Assertion and Badge Class. I wonder whether in the future we might want to break the built-in nature of these links, so that we could do something like have a prototype Badge Class with no pre-defined issuer. And then, in the Assertion, we could recreate the missing link between Badge Class and Issuer, in effect publishing a badge class template that could be used by any issuer. We'd still have the nested structure in all hosted and baked assertion copies. 

Too loopy an idea? Is there a better way to create badge templates that could be used by multiple issuers? -Nate

[Nate Otto]

It sounds like you're suggesting an endorsement of an Issuer. We were talking about how the Endorsement Working Paper is focusing on endorsement of a badge class for its user stories, though I would encourage us to use language that doesn't close off the possibility of endorsement of the other two basic Badge Objects (Issuers and Assertions).

I'm interested to hear how you might describe the limits within an Issuer endorsement so that it would be possible to tell that an endorser trusts X, Y, and Z of their badge classes (but not A or B). This would be a useful construct, but I wonder what metadata fields in the badge classes we could tie the endorsement to in order to craft an effective rule that does what we want.

Or maybe you're not even talking about Issuer endorsement, and this could be done through a type of Badge Class Endorsement that

It wouldn't be hard to endorse several badge classes with one endorsement perhaps, even perhaps Badge Classes that have not yet been created if we can figure out how to write rules that will let a validator determine whether or not a particular endorsement applies to a particular Badge Class+Issuer pairing. Then we could solve some of the problem around it being hard to include endorsements in badge metadata if the endorsements were created after badges had been issued under the endorsed Badge Class.

Nate

On Wednesday, September 10, 2014 12:03:16 PM UTC-7, Serge Ravet wrote:

[Serge Ravet]

Just a few more pennies ;-)

What I understand from the working paper is that endorsement is related a badge class AND an issuer, not the sole badge class. This makes sense as the value of a badge is in the trust relationship, something only possible if the issuer is trustworthy. Endorsing a sole badge class would be risky as a rogue issuer could issue badges and discredit the endorser. So, the most important element in the endorsement assertion is the issuer, less the badge class itself.

If we agree with this shift of balance of the assertion from the badge class to the issuer, we can now imagine a mechanism where a badge could be issued only if the issuer is endorsed/accredited. Of course, issuers could still be self-endorsed, which is today's situation: when an issuer issues a badge, it states "I trust myself to issue that badge", just like a self-issued badge (by a badge holder) states "I trust myself to do this and that." Every badge issuer holds an implicit self-endorsement assertion!

Some forms of endorsement (accreditation) create a context where the issuer acts more or less as the *proxy* of the endorser. The endorsing mechanism we are designing would be most useful if we were able to ensure that only endorsed issuers were able to issue a specific badge class — instead of asking the end user to make sense out of the various issuers, accredited or not, for a particular badge class.

I'm under the impression, may be false, that endorsement is mainly envisioned as a means to provide more information about a badge class. I would suggest that it could be also a means to control who is entitled to deliver a badge (badge the badger) or a badge class. We would then have a whole gamut of situations from 'endorsement as accreditation' (only the accredited organisations would be able to deliver a particular badge class) to endorsement as a 'like' (mainly inconsequential).

I see 3 main cases for endorsement:

1) Endorsement of an issuer for the delivery of badges of one or more classes

2) Endorsement of an issuer for the delivery of badges of any class

3) Self-endorsement of an issuer for the delivery of their selection of badges

NB: an endorsement assertion is also a self-endorsed assertion! They are at the origin of chains of trust...

And their associated behaviours

1) Only endorsed organisations can issue badges from those classes. The issuer *is* the endorser (the actual issuer is simply a proxy acting on behalf of the endorser)

2) There is no restriction to the kind of badges the issuer can issue. The issuer can present its accreditation for the delivery of badges in combination with other professional accreditations

3) The situation we have today, where anybody can do anything with no quality assurance/control

These cases are not hypothetical. The first one matches the delivery of qualifications designed by awarding bodies through accredited centers that can be independent organisations or further education colleges (c.f. UK). The second one too; UK awarding bodies have developed a qualification for assessors and internal verifiers, so every professional in a particular domain holding the assessor award can assess other professionals in their own domain of expertise. It is the combination of the assessor award (in our case, it would be "badge assessment award") with the professional expertise of the assessor, monitored by the internal verifier (QA) under the supervision of the awarding body.

While this sounds very much related to formal learning, this could also work in the context of informal learning: someone could design a badge and only allow the people she trusts to deliver that badge. One of the conditions for delivering that badge could be the possession of one or more particular badges (like the "badge assessor award"). Another condition could be the membership of a professional network, so if a particular badge was delivered to someone who is not a member of the community, then the badge would be displayed as incomplete or invalid - or not at all. There should be no limit on the number of conditions. When the conditions are met, the badge is sent back along the chain for signature.

How could that be enforced? Do we need more metadata and/or services?

The solution to our problem is the ability to express chains of trust — today we only have 'silos of trust' and there would be no real benefit in treating endorsement as an extension to those silos. Chains of trust can have multiple links, they can be intertwined to create networks. The metadata we have today is sufficient to represent chains of trust: an endorsement assertion links the endorser with the endorsee and the criteria could be badge classes for which the issuer is endorsed. In turn the issuer of a badge is connected to the holder, who can also deliver badges to colleagues or peers, etc.

So, in order to know whether a badge issuer has the right to issue a particular badge (or is endorsed), we could go to the backpack of the issuer and check whether it holds the right credentials, like an endorsement badge. The endorser could issue multiple endorsements to multiple organisations. The verification mechanism could then check whether the issuer of the endorsement assertion knows the badge issuer (who is the endorsement holder).

Making issuers have a backpack (or a personal data store) would reduce the current asymmetry of the OBI and facilitate the establishment and verification of chains of trust.

Now, how could we block someone issuing badges for which endorsement is mandatory? This could be done through a policy enforcement point (PEP) integrated in the badge issuing mechanism and in the backpack. This is the kind of technology currently implemented in trust architectures (c.f. OAuth and UMA - Kantara). a PEP could also be useful to address conditions for the delivery of a badge, like verifying the credentials of the issuer and of the candidate (having specific badges, xAPI statements, age, etc.). We could also imagine that the badge (instance) is signed by the endorser — the issuer pushes the badge to the endorser which then checks that the issuer is legitimate, signs the badge and pushes it to holder's backpack.

One question we had to address was: how to display  the name of the endorser on a badge? Why limit the display to one piece of information to enforce credibility, while there are probably many more worthwhile displaying: various accreditations, badges, evidence, narrative, etc. ? In the case of multiple endorsements, may be there are ones more relevant than others? Also, the badge issuer might have lost the original endorsement, or gained it afterwards.

In order to give the issuer control over what is displayed in the badge, the issuer could attach its own self-asserted badge containing the original endorsement assertion as evidence (or a narrative linking to the endorsement assertion). The badge at the end of the chain would simply point towards the self-asserted badge held in the issuer backpack.

This approach would also help us to address the difference between the individual acting on behalf of an organisation issuing badges and the organisation itself: the individual is 'endorsed' by the organisation to deliver badges on its behalf. The chain of trust would then be:

global endorser -> issuing organisation -> individual (proxy of the organisation) issuing on behalf of the organisation (proxy of the endorser) -> badge holder...

There are certainly more efficient mechanisms to reduce the payload and increase data resilience, but my purpose here is just an attempt at finding general solutions to particular problems.

To respond to your question relative to metadata, Nate: at first approximation, there is a lesser need for more metadata than a greater need for less asymmetry. With a less asymmetrical OBI, the backpack could become the natural and unlimited source of metadata. It is why, reducing OBI's current asymmetry should become a priority, not just a 'nice to have.' 

--
You received this message because you are subscribed to a topic in the Google Groups "BA Endorsement Working Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ba-endorsement/BGCtoXAXkNQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ba-endorsemen...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ba-endorsement/f16f1c73-10c9-4cf3-b01f-5fa7834a0b9d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.