- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Mon, 23 Nov 2015 10:02:58 -0800
- To: Benjamin Goering <bengoering@gmail.com>
- Cc: public-openannotation <public-openannotation@w3.org>, Web Annotation <public-annotation@w3.org>, "iiif-discuss@googlegroups.com" <iiif-discuss@googlegroups.com>
- Message-ID: <CABevsUFrLZT51a5yH62rHnO712Ucx2MyuJ-FXaDWe=LzSOFH9w@mail.gmail.com>
For authentication (authorization being purely business logic, based on the identity provided by the authentication system), the IIIF community is using a system that's derived from OAuth2, but for several reasons is not identical to it. The system and differences are described here: http://iiif.io/api/auth/0.9/ It allows for client registration, as well as both token and cookie based identity management. The use cases for IIIF involve both JSON, including annotations and other content, being requested via XMLHttpRequest as well as binary content (such as images, but not exclusively) being requested via regular browser actions based on the DOM. The rationale for this new spec is that different content providing institutions already have very different authentication and authorization requirements, and are unlikely to change quickly if ever, and if so they're even less likely to all converge on a single system. So the client needs to know where to go to allow the user to use their auth system, and then receive a ping that they should try again to do whatever action required authorization. Any questions or discussion would be great to join and/or copy the IIIF list: iiif-discuss@googlegroups.com Thanks! :) Rob On Thu, Nov 19, 2015 at 11:26 AM, Benjamin Goering <bengoering@gmail.com> wrote: > Is there a wiki page that lists implementations of web services that speak > OA? > I did a quick search but could only find. > https://www.w3.org/annotation/wiki/Existing_Protocol_Implementations > > 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? > http://labs.europeana.eu/api/authentication > > 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 > API. > > 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 - > linkedin.com/in/benjamingoering > <https://www.linkedin.com/in/benjamingoering> > -- Rob Sanderson Information Standards Advocate Digital Library Systems and Services Stanford, CA 94305
Received on Monday, 23 November 2015 18:03:30 UTC