Are there "standards" for Registering to Call an API

From IIW
Revision as of 12:25, 3 February 2011 by WikiSysop (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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:

  • Being able to automatically register for an API key in 2 scenarios:
  • 4th party (service provider e.g. DISQUS)
  • Developer not present (e.g. the Portable Contacts problem)

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?

  • Can't call a new service transparently (PoCo is an example)
  • 4th party scenarios are tricky (see password anti-pattern)
  • Need to update code/config for each new provider
  • Can't just copy existing code / use widgets
  • Behind the firewall (before you push to production)
  • Lifecycle is a dev/qa nightmare
  • Similar to certs / b2b problem (agreement of endpoints)
  • Barrier for developers who want to party
  • This is the password anti-pattern for application developers (e.g. RPXNow)
  • Service accounts to get an API Key (need a FB account, or a WLID account
  • Prove you own the domain

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