Key formats compatible with Linked Data Representations

[Nate Otto]

Hi, all

As we move toward Open Badges 2.0, one of the things we need is to understand how encryption (public) keys are represented on the web, particularly in Linked Data, but also in various "plain JSON" formats and others (PEM, ASC).

I'm not an expert in this space, so hopefully you all can help me out so that we don't accidentally introduce any incompatibility between Open Badges and what is needed to use blockchain-constructed identities in the badges world.

Here's a shared document we can edit (if you don't fancy trying to provide code examples by email or in Google Groups webform.. bleh! Write in Markdown!): https://usecanvas.com/ottonomy/key-format-examples-for-credentials/3GqZFPflxJYeBxHktRVKkf

1) What key format(s) are used and referenced in your corners of the web, and especially in the world of Linked Data? Also, how do key identifiers used in blockchain communities compare? Are these different arenas compatible? 

2) Is the JSON Web Key (JWK) format used anywhere cool? https://tools.ietf.org/html/rfc7517#section-4 and is there a context file that could make this into Linked Data available in the wild?

For context, Open Badges v1.1 (current) use JWS tokens, and validators are known to accept both RSA and EC keys (JSON Web Signatures can use many different types of algorithms). Badge Assertions reference PEM public keys available over HTTP. 

Some interesting work is being done on the proposed Linked Data Signatures spec that proposes some more Linked Data-native structures to describe keys and key owners.

Our goal: Understand key formats held by users of Linked Data and blockchains so we can evaluate what recommendations to make and options to support as part of the Open Badges Spec 2.0.

Nate Otto

Director of Technology, Badge Alliance

badgealliance.org