Re: A migration path from OAuth to WebID

(bcc: payswarm-dev@payswarm.com)

On 06/21/2010 03:28 PM, Dan Brickley wrote:
> On Mon, Jun 21, 2010 at 9:22 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
>> The following is a conversation that Dave Longley (Digital Bazaar's CTO)
>> and I had concerning a possible migration path from OAuth to WebID. The
>> discussion focuses on how we can build some amount of WebID adoption
>> without depending on browser manufacturers to fix the client-side
>> certificate UI bugs that currently exist.
>>
>> This came up because we're in the middle of doing our OAuth
>> implementation for PaySwarm+OAuth (purchase licenses to view pages via
>> OAuth - use-cases blogs, newspapers, magazines, etc).
>>
>> http://payswarm.com/pipermail/payswarm-dev/2010-June/000032.html
> 
> Thanks for this. I skimmed and didn't see discussion of this point,
> but excuse me if I missed it:
> 
> OAuth v2 (an IETF work in progress w. implementation tracked by
> Facebook and others) looks to be leaning towards using SSL/TLS in
> several places, rather than the ad hoc tricks of OAuth v1.0x. How does
> this affect your plans for migration / interop?

We think that OAuth 2 is generally going in the right direction, but
haven't done an implementation of it, so take the following with a grain
of salt. OAuth should be using SSL/TLS for almost everything - no reason
for it not to... worse - OAuth1 re-invented the Digital Signatures wheel
(in a bad way).

Passing credential secrets over the wire seems like a really bad idea in
OAuth 2. We haven't commented on that yet, but intend to at some point.

I think WebID has a place in both OAuth 1 and OAuth 2 - for establishing
the OAuth Consumer credentials in some way. We're really just talking
about how to establish a set of client credentials.

You either use a Consumer Key and a Consumer Secret (which is what you
do now in OAuth 1). You could alternatively use a Web ID URL (Consumer
Key) and a Web ID Private Key (Consumer Secret) - this is what we'd like
to see happen in both OAuth 1 (as an extension) and OAuth 2 (as a core
part of the spec).

Note that this would not affect the Resource Owner (User) at first, as
the OAuth mechanism would still look the same to them. We /could/ get
Resource Owner's using WebIDs in the future if the browsers had
better/more intuitive support for client-side certificates.

Ideally, you'd use SSL/TLS for securing the communication channel at all
times - your WebID would be the client-side SSL certificate.

<keygen> provides a cross-browser way of generating the certificates,
but we can't count on that working until the browsers come together and
decide that WebID is a good way forward. WebID shouldn't position itself
as dependent on the Web Browser manufacturers to make progress.

So, we may have better luck with getting people to adopt WebID if we ask
the Service Providers (Twitter and Facebook) and the Consumers (apps
like Hootsuite, and the services that connect to Facebook) to think
about using WebIDs for the Consumer->Service Provider credential
establishment mechanism.

Going that route, instead of waiting for browser manufacturers to
implement WebID and User's to pick up on why WebID is a good thing, we
might get a better first-crop of implementations by asking the more
technology savvy first-adopters/implementers to work with the
technology. We could then build off of OAuth/Cloud Authorization's use
of WebIDs to provide a launchpad for WebID's movement into the browser
and User-facing UIs.

In short:

* WebID is compatible with both OAuth1 and OAuth2 (with minor tweaks).
* WebID is compatible with SSL/TLS client certificates.
* WebID can be used as a Universal Identity (preferences, likes,
  social network, etc)
* Focus on WebID's use in backend OAuth code.
* Use WebID's success in backend OAuth code to drive WebID's
  success in frond-end User-facing UIs (browser, universal login)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Myth Busting Web Stacks - PHP is Faster Than You Think
http://blog.digitalbazaar.com/2010/06/12/myth-busting-php/2/

Received on Tuesday, 22 June 2010 02:15:25 UTC