Mozilla Open Badges

We will be announcing our plans for Mozilla Open Badges (OBI) shortly.  We were finalists in the Digital Media and Learning competition this spring and are very excited about this movement.

A Partial Farewell To Flash

For years, to my occasional annoyance, I always ended up the Flash guy even though I'm not a graphic designer or even a front end designer.  It was much simpler than that, I just could never get anyone else to be the Flash guy.

Actionscript is an interesting mix of typed and untyped programming, I found this model quite useful.  In conjunction with Flash Media Server, we've been able to make a fairly secure badge representing one's credential on our first go round with SIGKAT.

But Flash has clearly hit its high water mark - the much publicized omission of Flash on iphones, the emergence of HTML 5 are a few indicators, obviously.

So we will be moving on with a non-Flash implementation of our badging components.  Until, and perhaps even after, we are satisfied with our non-Flash approach, we will continue to provide the Flash based badges.

PHP and Drupal Client

A key pillar of SIGKAT's plans for increasing the breadth of credentials currency is ease of integration of our API.  A major component of this is creating client side toolkits for various languages and platforms.

Today we started up a project for Drupal that will serve 3 purposes:

• Enabling the countless number of Drupal sites.
• Development of a lower level generic php wrapper for the SIGKAT API.
• Give us a good demo/test client site.

Several other considerations informed this choice, including the groad popularity of Drupal in an innovative community and simply that we have some fairly in-depth recent Drupal experience so we can make rapid progress getting to a prototype.

We are targeting Drupal 7 initially and the project, still in sandbox stage, can be seen here.

As well as simply getting out a prototype, we expect to gain an understanding of the form and function of a SIGKAT API encapsulation that we will then apply to other similar projects.

Docs and API Metadata

I 've been in the trenches the past 1.5 weeks doing API documentation.  This was Dakota's big idea, which has turned out to be an excellent one.

The SIGKATA API provides a metadata structure for our app model at sigkat.com/services/api/model.  Metadata for individual classes in the model can be accessed at sigkat.com/api/model/<class name>, for example, sigkat.com/services/api/model/CredentialType.

We generate all our class and other structures specs from this metadata as well as many of our UI components, editing dialogs being an obvious example.

Doing the documentation this way helped us straighten out some issues in the model metadata.  Eventually, we will expand this facility such that sigkat.com/services/api will return a metadata structure for non-model api resources, but we haven't gotten to this yet largely because we don't have much in the way of non-model api resources yet.

Draft API Manifesto

Here is the first cut on the API Overview Thesis.  The ideas are there, but the formatting/presentation is not and it promises to be a messy cutting room floor.

You can see the live version here, which will undoubtedly be changing.

Overview and Design Goals

 

SIGKAT provides a domain neutral API for creating, submitting, and verifying credentials. Our purpose is to increase the value of credentials by means that can be broadly divided into two categories. The first is reducing the impedance in credential economies. The second is broadening the currency of credentials.

This reduction in "heat loss" in credentialling activities translates directly into realizable value for existing participants in credential ecosystems as well as lowering the barriers to entry for new actors.
Impedance in credential economies is reduced via considerations of both technical and human factors. Technical issues include an easy to use json/REST API, a flexible object model, and, most importantly, much latitude in how SIGKAT credentialling features may be incorporated into other applications.

One major human factor is addressed by a design that allows credentialees and issuers to specify the level of privileged information and qualifying requirements that are necessary to satisfy the trust and reliability requirements of their credential types. Another important human factor design goal is absolutely minimizing the SIGKAT footprint in the end user's exercise of credentialling capabilities.

Finally, a human factor that should be clearly stated is that although we do provide an end use UI, SIGKAT ultimately is not a destination site. Our design goal and primary use case is end users engaging in occasional and incidental credentialling activities in the course of their primary engagement with an API client's activity.

To this purpose and to our engineering best practices, SIGKAT's public facing site is entirely built upon our API; we do not avail ourselves of any private or undocumented features. Other than account creation, anything that an end user can accomplish on our site, an API client may incorporate in their activity. And addressing issues surrounding account creation via the API is on our Roadmap.

Broadening the currency of credentials is also the subject of a several pronged strategy that, again, has both human and technical aspects. On the technical end, and possibly an economic one, we service both supply and demand side features. That is, providing API features to allow easy incorporation of both credential issuance and acceptance/verification at third party activities.

Our technical strategy for supporting broad currency includes releasing higher level API wrappers that can be dropped into popular application frameworks. Included in this are use cases where API clients extend and relay the SIGKAT API and become fully featured credential API providers themselves.

At the other end of the spectrum, where an API client is interested in simply a single point of functionality such as only verifying user credentials, we provide authentication schemes and resources that are lightweight and of minimum impact for clients and their users.

Finally, the human factor that is relevant to currency but even moreso to any success is that SIGKAT must be an honest and secure broker of credentialling information. In no way is our "product" users or their data. For more information, please see our Terms of Service and our Privacy Policy.

Ex Nihilo

We went live today at www.sigkat.com.  Yes, we are totally pre-alpha and missing any number of critically important chromosomes.  Nonetheless, this isn't the sort of milestone people, or small insignificant startups, pass every day.

So hooray for us!  The beginning of the beginning of the end of the beginning or something like that.

Carry on!