This note gathers an overview and good practices on authentication methods (vocabulary+API) for pushback. This is an early draft and a work in progress. Please feel free to add yourself as a contributor.

main responsible:

contributors:

Back to pushback home

Authentication: pushback - Write Data Back From RDF to Non-RDF Sources

Index

@@TODO: take http://www.w3.org/ns/auth/acl into account

Authentication for the RDF site

The key interaction is the initial 'login' which will generally authorize CRUD operations via various mechanisms (Webform, WebDAV, SPARUL, Tabulator, API etc.). After this login operation, subsequent authentications can be via a token such as a cookie or session, as appropriate.

Auth via FOAF+SSL

This is achieved by sending a client certificate to the RDF site, and proving via PKI that you have ownership over a public FOAF file. This kind of authentication has the advantage that you can readily obtain semantic data from the external file about the user that is editing the resource. Figure 1 depicts the FOAF + SSL protocol adapted to the pushback architecture.

Auth via username / password

A more traditional method, but you generally lose semantic data unless you have recorded some via a registration process.

Auth via API key

Some systems will allow you to access them via some kind of shared secret such as an API key. This may or may not identify the user.

Auth via OpenID

As per login above however, a 3rd party may manage your login credentials. In some (perhaps rare) cases it may be possible to glean FOAF information from an OpenID using FOAF autodiscovery. Figure 2 depicts the OpenID protocol adapted to the pushback architecture.

Auth via OAuth

Enables web sites or appplications to access Protected Resources from a Service Provider via an API without requiring the User to disclose his Service Provider credentials.

Open Access

Finally, some systems may allow all users to access and change the resource. Normally you will still have the IP Adress of the User Agent that made the change.

Other

Multi factor authentication using some of the above can be applied, as well as other techniques, such as biometric, keyfob, USB tokens and many others. We will aim to pick the appropriate and common patterns in order to give a good balance of usability and security.

Authentication for the non RDF destination

This will need to be looked at on a use case by use case basis, depending on which policies the non RDF site operates. The autthentication methods described in the previous section can all apply. However an important differences is that there cant be TWO possible interactions with the 'downstream' resource.

Via the site that had the document changed

Interactions between the site that hosts the original RDF document, and the non RDF site (e.g. dbpedia/wikipedia) will have to be considered on a case by case basis. This section will be expanded as patterns are tested.

Via User that changed RDF document

Whilst this might not be considered in the spirit of pushback, it may be the only means to alter a resource. In a system such as Oauth, both a consuming website and a user agent work together to authenticate and authorize, but passing request and access tokens between each other. Such a policy is also operable via pushback.

Examples of Non RDF Authentication schemes

Twitter

Many Twitter API methods require authentication. All responses are relative to the context of the authenticating user. For example, an attempt to retrieve information on a protected user who is not friends with the requesting user will fail.

For the time being, HTTP Basic Authentication is the only supported authentication scheme. When authenticating via Basic Auth, use your registered username or email address as the username component. Session cookies and parameter-based login are known to work but are not officially supported.

The OAuth token-based authentication scheme will shortly be offered as an experimental beta release.

> curl -u username:password -d status="your message here" http://twitter.com/statuses/update.json

http://apiwiki.twitter.com/REST+API+Documentation#Authentication

Flickr

Any applications wishing to use the flickr authentication api must have already obtained a flickr API key. In addition, they must configure the following settings, attached to the API key:

Application title Application description Application logo graphic (max 600x300, recommended 300x90) (Optional) Application 'about' URL (Optional)

A 'shared secret' for the api key is then issued by flickr. This secret is used in the signing process, detailed in section 8.

Applications can then choose one of two authentication methods - web based or non-web based. Each application key may only be associated with a single authentication method.

Example: http://flickr.com/services/auth/?api_key=[api_key]&perms=[perms]&frob=[frob]&api_sig=[api_sig]

http://www.flickr.com/services/api/auth.spec.html