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.
