From MashupCamp

Contents 1 Open Authentication and Authorization for Mashups 1.1 Problems 1.2 Solutions 1.3 Permissions / Examples

Open Authentication and Authorization for Mashups

This session was about the challenges of doing authentication and authorization (thus AuthNZ) for mash-ups in an open, decentralized, and user-centric way (thus OpenAuthNZ). So what's the problem? Consider the many mash-ups and services that ask you for your user name and password for a third site. It's not a great idea to give out your password to anyone who asks; yet at the moment that's often what you have to do in order to let the mash-up access your data or do things on your behalf. It's also not great that you need to remember and juggle multiple user names to get a mash-up hooked up to multiple services.

OpenID helps solve part of the problem for services that accept it; you now need only one user identifier to tie services together. OpenID also helps avoid the need to enter a password, because that's between you and your OP, not part of the protocol. But OpenID by itself is unusable for many mash-up services because it only implicitly authenticates an in-browser session for a user present at the keyboard. It doesn't help when you need to get some explicit token to pass around to services to prove that the user authorized you to do something on their behalf. It also doesn't address the impersonation problem; you would ideally like to be able to give services only limited powers (don't send mail as me, but go ahead and check my calendar for updates). OpenID doesn't address authorization or 'deputization'. Finally, you would also like to be able to set up a permanent trust relationship with a service, letting it do things for you when you're not present at all; and you'd like to be able to revoke this trust at any time.

All of this has been solved, many times, but all of the pieces haven't been put together yet in a standard, simple, decentralized, user-centric, and deployable way. There's an "OAuth" group working on standardizing at least some of this; I was hoping to generate some interest in this, see what people thought of the issues and problems, and find out what else needs to be done.

Problems

• passwords - give your password to every new mashup/service combination
• impersonation - every mashup is impersonating you
• act-on-behalf-of (agent) even if user is absent
• attribution of data (url fn uid?) - openid, authoritative source
• Many solutions today: AOL OpenAuth, Google AuthSub, Yahoo BBAuth, Flickr API, ...

Solutions

• Linked "accounts"
• Authorization keys
• OpenID alone solves the many accounts and password problem, not impersonation problem, and doesn't deal with on-behalf-of problem

1. OpenID
2. Open Auth[nz]

Permissions / Examples

• Read mbox
• Write/send mail
  • Read/write dichotomy
• Roles?
  • Reading email (R)
  • Managing email (RW)
  • Sending email (RWS)
• Want central authorization service (tied to OpenID OP)
• Would like to say "Allow {service} to {X} {service2} on my behalf {forever|for time period Y}"
• Need some general X's (impersonate me | read | write) and specifics (read contact list only)
• Would like to be able to specify rules for a class of "known" services (all social neworking sites can do X for me)
• How do we identify services and sub-services? (Can they have OpenIDs, e.g., the MashupCamp event can read my notes tagged MashupCamp?)
• Note that a sufficiently fine grained permissions prefs service also has a really good map of service capabilities across the web :)

Follow-ups: Go to http://groups.google.com/groups/oauth