Are there "standards" for Registering to Call an API

Conference IIW8 Room/Time: 6/A

Convener: Angus Logan

Notes-taker: Angus Logan

Attendees: Everyone. Lots from Microsoft, Google, Yahoo, Plaxo, MySpace

Technology Discussed/Considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

0) Are "API Keys" / "Registration" required

Why pre-registration (identify app friendly to consumer, good way to shut off or give more permissions, give stats back re. popular *apps)
Value add: Statistics / nice UI
ToS compliance
Business Model
Throttling / DoS prevention
Varying levels of permissions (read/write)
Who is the developer (contact them for issues etc).
Can group the API keys together for reasons of blocking etc.

1) Is anyone doing this?

Google auth sub allows you to work in unregistered (gives you scary screen) (progression from pre-registration)
Unregistered Oauth for Google Friend Connect (no API keys) pass in the domain (no consumer key)
OAuth discovery Draft 1 (old and was removed from later drafts)
Anonymous/Anonymous - developers can use it (solves the barrier to entry, but doesn't have upside of API Keys)
Facebook do the following: you are on 4th party, and pop a window to get the API key (and secret), and copy/paste it to 4th party, and then 4th party can set the properties using a dictionary.
Open ID Oauth hybrid has something

2) Is this useful (enough to do the work)

Doing something like OAuth to create API keys is a no brainer and is coming next
Focusing on non-developer present creation of the API key is what we are focusing on

3) How will people abuse this functionality?

Create a ton of API Keys for many phishing sites (to fly under the radar of abuse)
When an API key gets shut down for abuse, create a new one automatically
ToS violation (terms of service won't be agreed to)

4) What is the current pain?

5) Solutions?

Lightweight unprotected function which requests some pre defined information and returns an API key. Then when end users go through the flow the experience is taxed (UI chunkiness or rate limited)
The provider may not know who the consumer is, but the end user may choose to grant permission to them.
4th party : have an API to create child API keys (FB have done a lot of thinking about JanRain)
Messina: Provide liberal access to the data/system, and when there is abuse, make the system selfheal (e.g. rollback)
ToS work around: we need to look at creating the "creative commons" of data exposed via APIs. I.e. the consumer can read the "rights"/"restrictions" around the dataset. Perhaps described as Standardized Terms of Service (is this being looked at by DataPortability) www.sciencecommons.org and www.opendefinition.org. question: will the lawyers be happy with a system accepting ToS?

6) Moving forward

Things to work on and next steps
4th party (and 5th party) provisioning of child API keys
setup and email thread w/ FB and G and Plaxo to riff on this and expand
Watch what FB does and the feedback, and also socialized what others are looking at
enumerate all of the use cases and post to wiki/blog
Walking up to an SP and doing some type of lightweight thing
Plaxo and G will riff on this and push out a prototype :: lead by Portable Contacts
enumerate all of the use cases and post to wiki/blog

Navigation menu