Re: [OpenID] UCI Idea: An iPhone OP (?)
Peter Watkins <peterw <at> tux.org>
2010-03-03 16:58:30 GMT
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.
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?
-Peter
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.
RSS Feed