Re: [ba-standard] Badge Creator-Issuer Distinction Post - Please Comment

Hi, Eric

I'm with you on this. +1. Comments embedded:

On Thursday, February 5, 2015 at 6:39:07 AM UTC-8, eric.korb wrote:
>
> My concerns are the following:
>
> 1) Will endorsements just become what "LinkedIn" endorsements have become: 
> worthless? Without any validation of authority to offer such endorsement, 
> where's the value or trust?
>

The way I see endorsement is as something that relies on a consumer's 
existing trust network and helps extend that, rather than something that 
gives a universal value "bump" to the endorsed badge. Just like the 
trustworthiness of an Open Badge itself depends on whether the consumer 
trusts the issuer to make those claims (and the verifiability that they 
indeed made them), the value of badge endorsement statements depends almost 
entirely on whether the consumer already trusts the endorser. If they do, 
then that trust can be extended to the endorsed badgeclass.

This is why I'm interested but not convinced that we need a separate 
statement inside the endorsement assertion extension about what 
qualifications the endorser has to be trusted in the subject area. Some of 
the same information could be found in that endorser's Issuer Organization 
object. However, it may be helpful to have a specific statement for the 
case where consumers would manually look at the endorsement and use it to 
make a human decision on whether to trust the endorsed badge.

2) What happens when an issuer changes the badge class meta-data?  Perhaps 
> the change is such that the endorser no longer wants to endorse the badge, 
> but will never know unless they keep checking (and would subsequently need 
> to revoke their endorsement).  What about badges that were already in place 
> based on the original badgeclass metadata?  I suspect the issuer will be 
> required to create a new badge, but how do you enforce that? 
>
> This is the reason the proposed endorsement extension allows endorsers to 
embed the entire endorsed badge object in the endorsement assertion itself. 
Then, if the endorsed object changed, consumers would be able to detect the 
change and invalidate the endorsement.

In the future, we could potentially add shortened versions of this data, 
like normalized/hashed representations, or just a Linked Data Signature of 
the endorsed object (presumably as signed by the object's creator, not the 
endorser, but...?). I proposed the simplest method that I understood with 
the idea that additional methods could be added later, as consumers develop 
the ability to understand them.
 

> I suggest that signing the badge class would ensure its definition is not 
> modified thereby adding trust (and value) to all constituents. 
>

I am coming around to the Linked Data Signatures approach to normalizing, 
hashing, and signing JSON-LD documents and am interested in investigating 
this further. I put in a pull request to the spec 
<https://github.com/openbadges/openbadges-specification/pull/24> this 
morning which doesn't mention signatures specifically, but should remove 
some ambiguity around whether the Linked Data Signatures objects would be 
permissable to add to 1.1 Open Badges. (They are valid additions, when they 
are mapped JSON-LD data). I hope to test out this technology in our own 
platforms at Concentric Sky and investigate moving to a recommendation, 
then requirement status in future versions of the OBI spec. Interested in 
your feedback

>
> Eric
>

Cheers,

*Nate Otto, Developer*
concentricsky.com