Re: [ba-standard] Considering the Open Badges crypto tech stack

On 11/25/2014 04:35 PM, Kerri Lemoie wrote:
> Currently the verification type is binary - either hosted or signed. 
> Should we consider extending the verification type so that it can 
> include both JOSE and JSON-LD and for that matter any type we
> haven't yet considered?

JSON-LD signatures (via Secure Messaging) provides that sort of
decentralized extensibility already. For example:

"signature": {
  "type": "GraphSignature2012",
  ...
}

That's what we support today via SM. But this might also be possible in
the future:

"signature": {
  "type": "https://anders.se/sigs#JsonClearText2015",
  ...
}

or this:

"signature": {
  "type": "https://thefuture.com/security#QuantumSignature2028",
  ...
}

The same kinda thing is also supported in JOSE, except that you need to
go through the IETF to "officially" add your signature mechanism to the
official registry.

> Verifiers/validators can then determine what they will accept. All 
> that the standard needs to provide is that a verification type is 
> required.

That's problematic for a variety of reasons:

1. It requires developers to implement two solutions instead of just
   one, which reduces the chances of the standard being picked up.
2. This is typically seen as a "failure to standardize". Given two
   choices, it's usually bad form for a group to pick both choices
   because it prevents group conflict at the cost of implementation
   burden on every company that now has to implement not one, but two
   different mechanisms. That is, the cost is shifted to the
   implementers where it is multiplied, when the cost could've been
   mitigated by the people putting the standard together if they
   would've just had the difficult conversation in the first place.

schema.org choosing to support Microdata, RDFa, and JSON-LD is a great
example of a "failure to standardize".

We should be providing a clear indication of the best practices to the
developers using the technology that we're creating. Every time they
have to implement two things that effectively do the same thing vs. just
one is a cost that we're shifting from ourselves (as the creators of the
technology) onto them (as the implementers of that technology). To put
this another way:

Cost of implementing JSON-LD signatures for Credentials: $50K
Cost of implementing JOSE signatures for Credentials: $50K
Cost of implementing both: $130K (+30% because of added complexity)
Cost to ecosystem: $130K * number of implementations (50?)
Total cost to ecosystem: $6.5M ($3.5M in waste)

I have no idea if the "number of implementations" up there is in the
right ballpark, but hopefully this gets the point across. Having a
difficult conversation upfront would help us remove $3.5M in waste from
a deployed solution (including many multiples of that required for
maintaining/debugging systems that utilize both formats running for
10-20 years).

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Tuesday, 2 December 2014 04:36:01 UTC