W3C home > Mailing lists > Public > public-openannotation@w3.org > November 2015

Web Annotation Protocol implementation wiki page? And thoughts on API Authorization

From: Benjamin Goering <bengoering@gmail.com>
Date: Thu, 19 Nov 2015 11:26:10 -0800
Message-ID: <CAGYs8_-aWDddHZqV=LVDiDbB3of-9JF_Nn84gi2oquj70iWUOQ@mail.gmail.com>
To: public-openannotation@w3.org
Is there a wiki page that lists implementations of web services that speak
I did a quick search but could only find.

My understanding is that API Authorization is intentionally being omitted
from the Web Annotation Protocol spec, and I think that's a good idea.

However, I do note that Hugo's API requires a human to register for an API
key via  form, then provide it as a 'wskey' parameter in requests. Hugo,
does your annotation API also support OAuth2 as described on this page?

And I'm curious what other implementations are doing for API Authorization

I think that an ecosystem of federated annotation providers (and a
competetive market of Clients that make use of them) would benefit from
machine-negotiable Dyanmic Client Registration
<https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-30> and Authorization
service/configuration discovery.

An example would be if I had a personal annotation store, and I annotated
something on Europeana.edu, my App could seamlessly register for a
Europeana API Key, guide the user through authentication and authorizing my
Client to post on their behalf, and also share that Annotation with Hugo's

Sounds a bit 'out-there', and OAuth2 specs aren't very prescriptive on
exactly how to implement this. However I have recently been implementing
<http://accounts.livefyre.com/.well-known/openid-configuration> a specific
flavor of OAuth2, OpenID Connect (Core
<http://openid.net/specs/openid-connect-core-1_0.html>, Discovery
<https://openid.net/specs/openid-connect-discovery-1_0.html>, and Dynamic
Client Registration
<http://openid.net/specs/openid-connect-registration-1_0.html>via pyoidc
<https://github.com/rohe/pyoidc>), and it is, in my opinion, very well
thought out and promising. It's also prescriptive enough (and configurable
enough) to afford for interoperable Clients.

I hope to prove this out with a UNXI tool I'm building, oidc-cli
<https://github.com/gobengo/oidc-cli>, such that the following works
$> client=$(oidc "https://accounts.livefyre.com" create-client)
$> annotations=$(curl -H "Authorization: $(oidc client-credentials
$client)" https://api.livefyre.com/annotations/?ldpstuff)

A Web Annotation Protocol tool could depend on this sort of thing to make
these sort of one-liners work to easily stream annotations to stdout, while
ensuring that Annotation services can still identify all the Clients of
their APIs (for auditing, rate limiting, emailing the developers, etc).
$> web-annotations --discover-for-url "
http://answers.livefyre.com/developers/app-integrations/sidenotes/" | jq .
| more
Benjamin Goering, Technologist
@bengo <https://twitter.com/bengo> - github.com/gobengo -
Received on Sunday, 22 November 2015 20:22:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:27 UTC