Re: [OpenID] UCI Idea: An iPhone OP (?)
Joost Van Dijk <joost.vandijk <at> surfnet.nl>
2010-03-03 20:57:34 GMT
On 3/3/10 5:58 PM, Peter Watkins wrote:
> 1a) Historically, consumer internet providers have not liked to
> allow customers to "run servers". TCP/80 has been largely blocked
> since Code Red in July 2001, TCP/25 blocks largely predated the SPF
> movement; I don't know about TCP/443, but I would expect many
> providers to block it, too. It's certainly not hard to imagine
> a cellular provider deciding that normal customers should *never*
> accept new TCP connections (What's that gonna break, FTP? Who cares?).
> Use a weird port and there's a fair chance that the RP's outbound
> firewall rules will prevent it from completing OpenID discovery.
> 1b) I can't see this working on typical wifi scenarios where the
> device has an IANA reserved address behind some SNAT gateway;
> simply no good way for the Internet-based RP to initiate a
> connection back to the micro OP. With weird ports, an intelligent
> middle-man service could map a public middle-man port to your mobile
> through a mobile-initiated TCP tunnel to the middle-man, but we're
> back to RP's outbound firewall rules.
> 2) Avoid the dyndns trust issue by using https URLs for your micro OP.
> (Nobody should be using plain http for OP endpoints!)
> 3) Sounds like a better scenario for plain old https client certificates.
> Or maybe InfoCard, but good luck getting Apple to bake that support
> into iPhone Safari.
Speaking of client certificates, I've been looking at Mobile PKI
technology, where one can use RSA keys safely stored on a mobile phone's
SIM for authentication (and signing) purposes.
If you are interested: here's a report:
We have integrated this technology into an Identity Provider (supporting
OpenID). What is nice about this technology is that it works with *any*
phone, because the application that does the authentication/signing is
placed on the SIM instead of the phone's OS.
I must add however that this also means a SIM is required that has the
app installed (together with some memory constraints), requires
cooperation from a mobile operator (as communication is over a mobile
network instead of over the Internet), and this technology hasn't been
deployed in many countries.
Still, it is kinda cool to watch yourself being logged into an RP by
entering a 4-digit PIN on your mobile phone
Joost van Dijk
> 4) iPhone: all this without background apps? How would you use iPhone
> Safari to authenticate to iPhone Micro OP if the two cannot run
> simultaneously? I don't think you can -- Micro OP would need to
> bind to a TCP port to listen for http requests, and Safari would
> need to connect to it. If they can't run concurrently, then you
> simply cannot make that TCP connection, right?
> On Wed, Mar 03, 2010 at 11:33:43AM -0500, David Fuelling wrote:
>> Wondering what people think about using as an iPhone (or Android/etc)
>> application as a personal OP.
>> Basically, the way it would work is as follows:
>> 1. Go to RP, get prompted with a login form.
>> 2. Turn on iPhoneOP application on your iPhone.
>> 1. iPhone App turns on lighttpd (or some other ultra-small web server)
>> to serve web requests from the phone and act as an OP.
>> 2. iPhone App then connects to a DDNS service that connects the
>> phone's current IPV6 address to the OP domain.
>> 3. The iPhone is now the user's OP.
>> 3. User signs into the RP, which then does the OpenID dance with the OP
>> running on the user's iphone.
>> 4. The user could login via the web, or optionally just get prompted on
>> the phone that a login is occurring - the user could then accept the login
>> and/or enter a security code (in case of a lost iPhone).
>> 5. User is logged-into the RP.
>> 6. iPhone App turns off.
>> Some initial thoughts I've had:
>> 1. Could this take us a lot closer to a user-centric identity? Imagine
>> if this software was built into the phone (so you didn't have to run an App
>> to make it work).
>> 2. Something like this would be interesting from a multi-auth
>> perspective. On the one hand, it could preclude the need for mulit-auth
>> because a person could turn off his OP when the app isn't running (thus
>> ensuring no RP logins without the phone....mostly -- see some security
>> drawbacks below).
>> 3. Alternatively, it could provide one multi-auth solution in that an RP
>> could be required to get an assertion from a "regular" OP and a user-centric
>> OP (like the iPhone) before allowing access.
>> Security Drawbacks (?)
>> 1. The user should trust his/her DDNS provider because somebody at that
>> provider could change the IP address hooked up to the domain backing the
>> iPhoneOP (without the knowledge of the user). However, this is an issue
>> with current OPs (the rogue employee problem). Either could be mitigated
>> with multi-auth.
> general mailing list
> general <at> lists.openid.net