You do support TLS session resumption already though. Session resumption is
where one HTTPS connection reuses the same handshake as a previous HTTPS
connection.

 

% openssl s_client -connect api.twitter.com:443 --reconnect

.

Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

.

Session-ID: C076F0B02BB71058612A0942794BE6365A4482CEF9D1B15D7CD98BF91234EBDB

.

Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

.

Session-ID: C076F0B02BB71058612A0942794BE6365A4482CEF9D1B15D7CD98BF91234EBDB

.

Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

.

Session-ID: C076F0B02BB71058612A0942794BE6365A4482CEF9D1B15D7CD98BF91234EBDB

 

 

From: twitter-development-talk@googlegroups.com
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi
Krikorian
Sent: Tuesday, January 12, 2010 12:33 AM
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Any iPhone Twitter apps with OAuth login ?

 

2.      Replace the manual PIN entry requirement with something else. The
OAuth 1.0a designers greatly under-estimated the poor usability of manual
PIN entry, especially on mobile devices. One suggestion off the top of my
head: allow OAuth 1.0 (in addition to OAuth 1.0a) if--and only if--all parts
of the OAuth authorization flow take place in the same TLS session (e.g.
using TLS session resumption and/or a persistent HTTPS connection when/if
Twitter supports persistent connections) and the application is registered
as a desktop app (not a web app).

i definitely hear the pain in the PIN workflow -- just as a quick point of
note, we're not set up to handle persistent HTTP/HTTPS connections at this
time.

 

keep the ideas going - loving this thread.

 

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

Reply via email to