From MashupCamp

This inactive page has been protected to prevent it from being spammed. If you need access to it, pleas contact us.

Contents 1 Access-control for feeds (RSS, Atom, FOAF, vCard, ...): HTTP Auth Basic doesn't work very well for Mashups, but URL-based identity does. Can we agree on how to do it? 2 Discuss this topic online 3 Attendees 3.1 Questions/Intro 3.2 Problems: 3.3 Discussion points: 3.4 Ideas to follow up on (potential solutions to #1)

Access-control for feeds (RSS, Atom, FOAF, vCard, ...): HTTP Auth Basic doesn't work very well for Mashups, but URL-based identity does. Can we agree on how to do it?

Proposed by Johannes Ernst. Rough notes by John Panzer.

Discuss this topic online

Attendees

• Joe Gasiorek of imeem
  
• Trevin Chow of Windows Live ID
• Johannes Ernst (blog) of NetMesh: LID, Yadis, OpenID, OSIS
• Joe G. - IBM social network
• Michael C. - Wired News
• John Panzer of AOL
• David Drinan - AOL
• Mark Carlton - HP Snapfish
• Alan Lin
• Fred Fillman - SFW partners
• Scott Rosenberg - Salon.com
• Mike Prince - Mobido
• David Recordon - Verisign (OpenID)
• Max - IBM Research
• James Littlejohn healthXY.com

Questions/Intro

• Do we need to solve access control for feeds?
• How could it be done in a uniform manner?
• If we want to provide different data to different people from same feed, need personalization built on top of identity.

Problems:

1. Who is doing the HTTP GET? (Proxying, ...) (11 votes for top priority)
2. Identity for individuals, groups, orgs, software
3. Propagation problem (services on behalf of). (combined with #4, 6 votes)
   1. 2 models: Opaque proxy vs. propagation model.
   2. one way: same ID across sites
   3. second way: confer limited rights to 3rd party
4. Joining IDs (aggregating, correlating IDs)
5. Who published data? (2.47 votes)
   1. Controlling distribution of data
6. How to simplify access to many applications for a given person (identity) -- avoiding walled gardens. (9 votes)
7. How to gain buy-in from providers for any solutions?
8. Cacheability.
9. Coexistence.

Drivers:

• Security (don't want to hand out Flickr ID to everybody)

Discussion points:

• Talking point: Username/password not scaling?
• Talking point: Privacy, misuse, etc.
• Existing practices, what will work today: Security through obscurity (protect the subcription page, not the feed itself, hand out obscure URLs). [2617] can be used to protect feeds, though insecurely. https+Basic Auth is secure but expensive.
• Other problems: Very hard for people to charge for content on the Web -- high overhead, getting credit card, etc. Cool if mechanism existed for low-security mechanisms (charging a few cents per blog article). Would be great if we could self identify to feed providers.

Need to identify on each get (1) who it is and (2) some optional proof.

Ideas to follow up on (potential solutions to #1)

1. Append UID to feed URL (personalized or just security through obscurity)
2. Add ID and credential (optional proof of ID)

How to add to protocol? General agreement on points #1 and #2. How to do it needs more discussion.

OpenID is a potential solution. Will talk more in a followup session. Also can talk about this at (Identity Open Space at Digital ID World in Santa Clara in September.)