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

Hi, all friends and mailing lists:

I think the OBI will for the future recognize that JWS signed 1.0 and 1.1
badges are valid. Even if we switch to the SM spec for some future OBI
version, a complete consumer tool should be able to understand and validate
these historically valid signed badges (even if there are very very few of
them in existence today).

I remain interested in wins achievable with the JSON-LD community's Secure
Messaging (SM) proposal. The finished signed document remaining JSON is
very attractive to me.

Before we make a final decision for the OBI on this issue, I'd like to
think of future directions we could go with either approach, and see
whether either of them cuts off any future wins.

* One of these might be encrypting OBI assertions so that they are only
verifiable by one particular consumer (at least without that consumer
revealing their private key). We could assume that the consumer could
divulge the decrypted version, but that it would lose its verifiability if
they did so.
* Another is "countersigning" badges, to indicate that both an earner and
an issuer are in consensus on an assertion.


I still need to do more research on both approaches before I understand
enough about them to be personally satisfied that I can contribute a final
vote to this discussion. (For example, what formats may public keys be
published in, how are those keys discovered, and how does this key
infrastructure contribute to organizations' and individuals' ability to
participate in other forms of encrypted communication?  -- I'd love it if
we could contribute to the development of a truly democratic public key and
trust graph infrastructure instead of building our own siloed solution on
the margins.)

*Nate Otto, Developer*
concentricsky.com

On Wed, Nov 26, 2014 at 10:13 AM, Eric Korb <eric.korb@accreditrust.com>
wrote:

> @Kerri @all (reposted)
>
> We had a deep conversation during our last Credentials Community Call on
> Nov 25, 2014.  May I suggest that you read the minutes (listen to audio
> reply) that can be found here: http://www.w3.org/community/credentials/
>
> IMHO, trying to support more than one signature type would not be the best
> course of action because it would make implementations really complicated.
> I expect the CCG to continue to evaluate the technical merits of JOSE and
> SM methodologies, but more importantly their applicability to
> micro-credentials.
>
> Thanks for the input.
>
> Eric
>
>
> On Tue, Nov 25, 2014 at 4:35 PM, Kerri Lemoie <kerri@achievery.com> wrote:
>
>> I'm a little bit late jumping in on this thread. I've been thinking about
>> Jason's message.
>>
>> 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? Verifiers/validators can then determine what they will accept.
>> All that the standard needs to provide is that a verification type is
>> required.
>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "BA Standard Working Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ba-standard+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>