See also: IRC log
<dom> OAuth mailing list at IETF
<dom> OAuth slides (for this presentation)
<dom> OAuth Intro
<dom> OAuth spec
<ted> David Recordon from Sixapart introduces himself and involvement with oauth
<ted> Blaine Cooke currently from BT, recently at Twitter introduces himself and involvement with oauth
Blaine Cook: will go thru the slides now
slide2
oath is delegated authorization. A way to provide access to your data which is private without giving out all your rights
(slide 3)
in 2006 there was an openid meeting. People were wondering if they could do open authorization out of the box without using openid. By the time that version 1.0 of the spec was reached, the communities shown in slide 3 had all participate din the process
(slide 4)
looked for an extraction of existing open authorization patterns from different existing technologies and use them in oauth
(next slide)
<ted> (slide 5)
We wanted these patterns to be useful, but flexible. Basic auth can be documented in 10 mins, other auth systems take much longer so basic auth wins because of this
(slide 6)
oauth is driven by people working in web companies. We count on this for adoption
(slide 7)
(slide 8....) how it works
<ted> (slide 12)
<koalie> (slide 15)
<koalie> (slide 16)
example of how it works. Two service provide flickr and a moo, that can makes cards using photos from flickr
we have user jane.. she wants to print some photos she has stored in flickr. moo can do it for her.
<koalie> (slide 17)
we are trying to build applications that can use private data in a limited way., so that moo can print the photos without having access to other stuff, such as her credit card information
<shepazu> I wonder if this has applicability to geolocation and info-sharing
because there could be a fakemoo that wants to abuse from this access
<koalie> (slide 18)
moo asks for a request token to flickr. Signs the request so tha tflickr knows that it's moo making the request
<marie> (slide 18)
<timbl> How does flickr know what moo's key is?
<dom> (slide 19)
flickr authenitcates moo, creates a signed token and sends it back to moo
<drecordon> Moo first gets a consumer key and secret from Flickr
(that was slide 18)
<drecordon> and then includes it when getting the request token
moo then gives the request ttoken to user jane and asks her to authorize the request token so that it can access the photos
jane asks that on flirke (slide 20)
<rigo> I wonder about relationship jane <-> flickr, if this runs foul, flickr can completely block jane
<ivan> (slide 21)
<dom> On timbl's question: http://oauth.net/core/1.0/#anchor6 says "The Consumer Developer MUST establish a Consumer Key and a Consumer Secret with the Service Provider." - I assume this means this is out of scope of oauth itself
<drecordon> if Flickr blocks Jane then she loses access to all of her photos anyway
slide 21:Jane tells moo. All set . I gave permission to flickr so that you can access the photos
<ivan> (slide 22)
<timbl> (presumably the secret is used at some point)
slide 22: moo exchanges the request token for an access token
(slide 23)
moo requests the photos that are associated with the access token
flickr complies and sends the photos
moo can continue requesting photos as long as the authorization token is valid
(slide 24)
points to note:
<tlr> I like the separation between authorization and identity here.
moo doesn't know who is jane on flickr, doens't get any information about jane's user account on flickr. Both the consumer and the user could be anonymous, without comprimising authentication
<drecordon> and then there is work going on of an OpenID and OAuth Hybrid which bring the two together
<rigo> privacy protection by intermidiary is not new, the problem was always privacy protection against the intermediary (here flickr)
it's API independent. oauth doesn't make any claims on how the requests hsould be structured. You can use HTTP, SOAP, or your own protocol. oath is just a wrapper around it
<rigo> can Jane set an expiration date for the token? Because a big loophole may be that Jane simply forgets about the token
tokens can be revoked. This is better than password access. You can revoke permissions with finer granularity
<ted> (slide 25)
(slide 25)
<drecordon> As tokens can be revoked, they could automatically be revoked by jane's provider at a given time if you wanted.
<drecordon> That would just be in the implementation of the provider
there are three signature methods HMAC=SHA1, plaintext (shared secrets over ssl), RSA=SHA1 (PKI)
<tlr> yeah, upgrade to SHA256 at some point
<rigo> I wonder about non-repudiation
<drecordon> there isn't enough library support for SHA256 unfortunatly :-\
<drecordon> we looked at it about a year ago
(slide 26)
signatures. A signature is computed over the URI, request parameters and oauth parameters. This is called a signature base string
<shepazu> might be interesting to bring up proposed Origin header
we don't sign HTTP headers, no x-www-form-urlencoded HTTP body
(scribe didn't get why those are not signed)
(slide 27)
<Ralph> [I wonder if it's safe not to sign the Host: header?]
signatures are not just limited to HTTP.
signature methods coukld be describe for any protocol. We currently have XMPP in addition to HTTP
(slide 28)
and (slide 29)
oauth request example
the request is a a simple GET for a photo. there's an HTTP host header
<marie> (slide 30)
the request with OATH is the same, with the addition of an HTTP authorization header conveying the oath data
such as the token, a nonce, timestamp, signature, oath version, etc.
nonce + timestamp is there to avoid replay attacks
<Yves> so basically oauth requires keeping state on the server side (to avoid replay attacks, for example)
(slide 31)
we get all this info and compute the signature base string. Shown in slide 32
slide (33-...) show the different parts of the signature base string
<tlr> Ralph, they seem to be reconstructing the URI, and include the host
<ted> (slide 35)
(slide 36) gets them thru the HMAC-SHA1 function and that makes the signature
(slide 37)
<ted> (last slide)
<Ralph> yes, but the server doesn't see the encoded host
<tlr> ralph, to check the signature the server needs to reconstruct the URI as well.
<tlr> if you look at the signed material on slide 36, the host is in there
issues: documentation is still hard to read, not ideal for implemtntors. OF course, learning curve harder than for HTTP basic auth
some API usability concers re: redirects
not perfect: doesn't solve phishing, brute force attacks
<Zakim> jose, you wanted to say missing host: header (agrees with Ralph)
jose: part of the request is not just the http get but you should include the host header in the signature
blaine: the host is included in the actual signature, i didn't highlight it in the slide
david: i saw a few questions about how the consumer key comes about
... that is where oauth gets a key and secret from a provider and them providing that is dependent on terms of provider
david: the consumer key could be provided by your service provided (flickr). This is up to the service. It could be provided off-band.
Blaine: there's some process right now to see if consumer key providing / negotiation providing could be standardized
<lattice> +1
<DanC> (last night I learned the term "bounce rate" in a presentation about a web site redesign that reduced the bounce rate from 89% to 15%)
<drecordon> From 4.2 "The Service Provider’s responsibility is to enable Consumer Developers to establish a Consumer Key and Consumer Secret. The process and requirements for provisioning these are entirely up to the Service Providers. "
<Zakim> timbl, you wanted to wonder whether there needs to be a form of redirect for administrative things like this which the browser treats separately
timbl: wondering if user could be more aware of redirects, rather than making it so transparent inside the protocol. Make for example a pop-up "login admin window" dialog box that warns the user what will happen next. Would this be useful?
<drecordon> http://oauth.net/core/diagram.png is also really useful
<shepazu> there may also simply be people who rethink the decision to use the resource
blaine: that would be useful
<DanC> (oops; the 89% to 15% [redirection in example website] redesign had nothing to do with oauth. sorry to distract)
david: if this would be inside browsers, we could tell the browsers this is a place I trust to hold my password (scribe: eg., like when you say "authorize cookies from this domain)
<dom> [this problem about being redirected elsewhere for admin purposes also happen on sites where you have to pay through a different site, and then go back to the original site to finish the transaction]
david: as long as a service is not asking for additional permissions, you won't see the redirects or pop up boxes again
<Ralph> blaine: "the consumer key can be trusted"
blaine: the consumer key could provide for accountability, usage permission, and permission granting for data. This could be useful
<Yves> I wonder if access can be timed (like allowing explicitely for 1 day)
<drecordon> @Ralph, blaine actually said the trusted comment
<drecordon> I've learned better than to use that word :P
<sandro> (smart toasters are not all that crazy -- they could be configured for each kind of bread (given information from the bread's manufacturer, and given the particular users preferences)... and for nutrition tracking, the nutrition changes depending on how it's toasted, etc... ! :-)
<Yves> sandro; toasters can contains lots of sensitive information, like what kind of bread you are eating ;)
<Zakim> ericP, you wanted to ask how much consumer_key manages phishing
<ericP> ericP: consumer keys (and their backing contracts) can be used against phishing.
<ericP> ... i imagine consumer keys by tier + identity, some delegatable.
<ericP> ... since this has no analog in basic auth, what use cases were driving this?
ericp: consumer keys and contracts could be used for phishing. We have identities separated from contracts. We can authenticate someone and then relate them to contracts. What was the use-case guiding this? what were your goals?
david: we looked at what amazon,
google, yahoo.. were doing. One of the use cases was knowing
which application was doing the request
... some of the application could be web based or desktop
based...
blaine: diggin's e.g. didn't care about authentication the users; just the consumers. I don't understand the reasons behind this. Maybe they didn't have a way of tracking from where the request was coming
they could track which agents were making the requests, but not the users
<Zakim> Ralph, you wanted to ask if the user has any way to know (to judge) the strength of a consumer key for a given provider? and to refer to slide 20
Ralph: In slide 20, when Jane is supposed to pass the request token. How strongly flickr trusts moo. What's the nature of the shared secret between flickr and moo? e.g., if there's a new moo security attack, how do I know if moo is secure against it, that the security request token sent to jane is protected against it, that it comes directly from moo
blaine: you could call flickr's help desk (laughs)
<timbl> Presumably there could be links from the flickr OAuth page Jane has to log in on which could have details or it all.
<drecordon> http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html
blaine: when you issue a consumer key, you have a request process that looks like a passport request application process. moo and flickr may use any number of approaches to authenticate each other, off- and in-band. flickr could show the contract and assurances it has with moo to Janet if Janet requests it before granting delegation
<Zakim> rigo, you wanted to talk about central intermediary and privacy issues
david: flickr could also tell Jane "hey we're not really sure if moo is moo. Are you sure yourself before proceeding?"
<Ralph> thanks, David; so there's a piece of the protocol that does allow flickr to caution Jane
<drecordon> it's more that there isn't a piece which forbids it ;)
<drecordon> and then the unregistered consumer extension is just an instantiation of it
rigo: is your service privacy aware? What happens if flickr refuses to grant a token? What's the liability issue status? Have you talked to lawyers about this?
<Ralph> Rigo: what about privacy? Have you talked about liability issues with lawyers?
<ted> there is far greater risk with giving credentials
david: if flickr doesn't support the moo service, it means that you'd need to give your flickr password to moo. You really don't want to do this. By supporting oath, you can restrict what kind of access moo will have to your flickr photos
<dom> a scenario where this matters: flickr could know that you're selling your private pictures e.g. to a porn site
<tlr> wait a second, flickr is ecommerce. I pay for their service, and I paid for my moo cards
<drecordon> @Ralph, then show me a weapon that is still a weapon and doesn't kill anyone ;)
<Ralph> david :)
<rigo> it is actually funny that you confirm my worst worries
<drecordon> if all tech tries to be perfect then we'll never move forward
<dom> indeed
blaine: oath gives you a much better legal framework to do legal decisions. For example, in case of moo doing something illegal, flickr could switch off all moo access. No need to revoke all existing passwords to do this
<drecordon> it needs to not make things worse and ideally make things better overall
<dom> can oauth support an authentication broker between flickr and moo?
<Yves> actually the user decides to make the relationship, it's not hidden as when you are using an auth tier in the loop
<drecordon> @dom, no it doesn't
<dom> ok
<tlr> drecordon, why can't you have recursion in the authorization interaction?
rigo: putting central entities is good for security, but it's not good for privacy. e.g. flickr could blackmail moo as far as they want.
<dom> can we timebox that discussion, please?
<tlr> drecordon, you could stack several oauth interactions into each other
<drecordon> @tlr, I bet that you could. It just wasn't designed to do so.
<drecordon> And yeah, you could stack them but then you have the user bouncing through multiple layers of redirects as the tradeoff.
<DanC> (I think rigo's point was only partly understood... )
<Ralph> agenda order 4,7,6,5
<lattice> rigo: addressing is zero-cost beyond the normal use case
<drecordon> @riko, I think it is more that as OAuth was being created there weren't members in the community who advocated for these sorts of use cases.
<DanC> (from ajax is a lot easier than from a headless client, e.g. a python script)
<rigo> drecordon, I would like to establish a contact to the Primelife projects
<drecordon> One of the first OpenID demos was actually fully Ajax, it just never got a lot of traction
timbl: this is a problem with openid. There are difficulties to use it from an ajax program. How does oauth stands here? How far can we separate the human from the redirects, how much can we tell them about them?
<rigo> if we could only get 1% from this project into oauth, it would already be worthwhile
david: there is mainly an assumption that humans are there during the request token phase. But once it has been exchanged for an access token, the human doesn't need to be there anymore
blaine: not sure if we can automate redirections. However, it's technical possible to set up systems where redirections are not needed. We have some work in this direction
david: oath requires redirects right now, but you could do it without redirects at some time.
<DanC> (I repeatedly get confused by the term "consumer"; to me, it conjures the user, a couch potatoe, not one of the service providers)
<Ralph> david: check-id-immediate mode allows consumer to ask the provider directly if the user has a current authorized session open and bypasses the user interaction
timbl: it would be nice to separate the authentication from the authorization.
<drecordon> @DanC, OpenID now uses Provider and Relying Party which makes things easier until we talk to normal people :P
<dom> :)
<DanC> yeah, I haven't seen one set of terms that makes everybody happy
<drecordon> http://radar.oreilly.com/2008/12/getting-openid-into-the-browse.html
<drecordon> I want that ^^
<Zakim> tlr, you wanted to wonder about API requirements for XMLHttpRequests
<Yves> the openid trend is to be provider, not consumer, and that leads to lots of real privacy issues
<drecordon> @Yves, I think that is an overstated trend. Relying Parties more than tripled last year up to over 30,000 public sites that accept OpenID sign in. The large companies generally start by being a Provider – which is the trend people see – but largely followup with becoming a RP as well.
<timbl> thomas: An alternative is for et client software in the browser to go get the data from flickr and then do stuff with it, with the ath just between the consumer and flickr, -- maybe phots are too big -- but that would maybe be better
tlr: re using oauth within ajax applications. I could see an application that's controlled by moo and have moo control the user's browser rather than do all the things by itself. Your feedback would be really useful in our xmlhttprequest and xmlhttprequest level 2 drafts. (got that right?)
<drecordon> An OpenID wrapup from last year :) http://openid.net/2009/01/15/momentum/
dom: how much oauth can work on mobile devices? What's the impact on speed, constraint networks?
<DanC> ("constrained network"?)
dom: on mobile networks with latency problems, ...
<tlr> s/security applications drafts/xmlhttprequest and xmlhttprequest level 2 drafts/
blaine: one of the design
constraints for oauth was for it to work on mobile devices. It
allows for more caching and is more lightweight than ssl. For
mobile devices that don't have an in-built web browser, we
thought about using bluetooth so that the mobile device can
connect to a real browser in a computer (behavior document by
flickr)...
... if you have a computer device without web access, you're
probably not using flickr anyway
<Zakim> tlr, you wanted to also note that the redirects occur during the authz phase only
<dom> right
tlr: Dom one of the points you were talking about redirections. The redirect happens where one party authorizes the other , but not afterwards. I don't think that the latency problem would have other impact
<lattice> tlr: thanks for clarifying
<DanC> (seems to me that in every case where OAuth adds a redirect, the human is in the loop so, while round trips on mobile are particularly costly, it seems kinda reasonable)
tlr: the larger phishing risk is if the redirection is not being sent to a trusted site but to a forged one
<tlr> I think we can't solve it, just like we can't solve people falling for liars in real life.
blaine: the phishing problem is a social one and one of education. I don't think we can solve this problem right away. The best approach here is to know if a site is known for phishing or is trusted
<DanC> (eek! yes, it's a social problem, but relying on user education is a recipe for failure.)
<tlr> But we might be able to make things easier.
<drecordon> I'll just paste this in here again :) http://radar.oreilly.com/2008/12/getting-openid-into-the-browse.html
blaine: going to the existing approach of "give us your username and password" is worst than what oauth proposes
<dom> is this something that you think would need standardization, drecordon? http://radar.oreilly.com/2008/12/getting-openid-into-the-browse.html
<drecordon> yes
<tlr> I'm not at all suggesting that "give me your user name and password" is better than oauth.
<timbl> If the browser warned you when you entered the same password for two different sites, taht might help two things.
<lattice> tlr: definitely ;-)
<lattice> timbl: +1
<DanC> (yes, browser extensions/changes (e.g. verisign seatbelt) seem pretty important; education user-agents is *much* easier than educating users ;-)
david: some time ago when I was working at verisign, we made some modifications to a browser where you could configure where was your openid server and your trusted servers. I'd like to see this approach, identity awareness, making its way into browsers
<Zakim> timbl, you wanted to ask about insisiting on ssl
<drecordon> this was what we created at VeriSign https://pip.verisignlabs.com/seatbelt.do
<tlr> timbl, interestingly, password managers do much of that. Part of the problem is with people not trusting password managers, and more importantly, sites not trusting password managers (because they don't trust the user's computer)
timbl: what may keep you from using the same password on two or more sites? Should the browser warn the user?
<drecordon> I think the larger issue with password managers is that they make things harder
<sandro> isn't OpenID the right solution to the many-passwords problem?
<tlr> sandro, nope
<DanC> why not, tlr?
<drecordon> @sandro, yes
<ted> blaine: if you are not logged into flickr and another provider is trying to make an auth request on your behalf then you should go to flickr
<drecordon> Berlin is good
<scribe> scribe: ted
<tlr> because it has its own set of problems.
<DanC> tlr, I'd like W3C to deploy OpenID all over, and I gather you're advising against. I hope to get to the bottom of that some time.
<dom> openid is ok for weak security, but not strong
<DanC> openid can be as strong as you like
<sandro> can openID be fixed, TLR, or is the concept fundamentally broken?
david: openid providers can go to the various designated providers and develop a stronger relationship with and help prevent phishing
<sandro> right, sorry
timbl: it doesn't matter how often you use your verisign (openid) signin
david: if we are trying to protect a user from phishing we can do so easier this way
timbl: or use public key and never a password with openid provider
david: openid.com allows for personal certs, browsers are all over the place wrt handling personal certs
<drecordon> *myopenid.com
<DanC> (client side certs seem to be designed assuming an enterprise situation; i.e. that somebody will force you to use them on pain of losing your job )
timbl: putting the name of the holder of the cert is now implemented in browsers
<DanC> (did we thank them, timbl?)
<timbl> DanC, Good Q :)
tlr: some of the wrinkles of
phishing to address
... delegation is the core of the problem
<DanC> (I expect it'll be a cold day in a hot place before banks delegate authentication)
<drecordon> banks would be great providers :)
<DanC> banks *should* be great providers; so far, they seem to have frighteningly bad web site builders
tlr: i should be warned if using
a password with a different site than intended, most password
managers in browsers do this
... most phishing sites try to sabotage this. it is a trade off
between usability and security
... the main concern for banks these days are computers that
are completely pwned
<dom> s/phishing sites/bank sites/ no?
<DanC> (why don't the banks work with ISPs to take zombies offline? it really pisses me off that researchers can identify millions of zombies and nobody takes them offline)
<drecordon> considering I woke up at 6am, I can stick around for awhile still
tlr: we need to be extremely careful if x worked in client software because people will not accept x on server side
<tlr> </speech class="toolong">
tlr: availablilty of software on client is not the limiting factor
<jose> intell. prop
<jose> plh: are there any IPs around oauth? what is your patent policy with re it?
plh: are there any ipr concerns around oauth, was there patent disclosures of the participants?
<drecordon> https://agree2.com/declarations/oauth-non-assertion-covenant
david: all the contributors
executed a @non-assertion covenant
... august of last year there was intent of creating the open
web foundation to deal with the ip problem
... it was something to be dealt with after the fact
<dom> I see two "on behalf of Google" in the signatories
plh: it was individuals or their organizations that made the disclosure?
david: combination of both
<drecordon> http://www.hueniverse.com/hueniverse/2008/08/oauth-licensed.html
<drecordon> The OAuth license has been signed by AOL, Citizen Agency, Google, Ma.gnolia, Pownce, Six Apart, Twitter, Wesabe, Yahoo!, and the individual contributors.
blaine: google, yahoo and sixapart ... ^^ see list from david
<Ralph> [is this list public?]
ralph: are those public knowledge?
david: yes
... this is something we are trying to make easier for projects
going forward, we went through this with openid as well
oauth ml is on google groups and it is pretty active
<DanC> (this one? http://groups.google.com/group/oauth )
<tlr> danc, yes
<drecordon> http://groups.google.com/group/oauth/
david: there is some work going on bringing a wg together in ietf, majority of community is google group
<drecordon> http://www.slideshare.net/Blaine/oauth-presentation
blaine: we had an ietf bof in minneapolis recently and in a holding pattern at present
<DanC> (I wonder if any/many of the wish-list items from our phishing discussion here are on the W3C Security Context WG's radar)
blaine: no charter yet but agreement it should go the standards track
<lattice> http://www.slideshare.net/Blaine/oauth-presentation
slides cc license
blaine: there are quite a few providers using it but some holding back that wouldn't if it were standardized
