the way i am envisioning the clients sending authenticated updates to the server is:
- the client(phone) generates a pub/priv key pair
- the client sends the user to the browser with the client's configured openid and the public key in HTTP GET parameters
- the server asks the client to do an openid login (if not already logged in).
- if the login is successful, the public key is associated with the openid and trusted
- updates signed with said key are accepted as authenticatied/trusted
this requires no SSL support on the server. public key encryption gives the user a big benefit in this case - a user can move all the location data from one server to another and know that the updates are authentic - its impossible for the server or service to tamper with the data as long as the private key on the phone is secure.
OpenID is implemented. A user status page could contain a random password. With a custom URL, the android browser can launch icecondor with the random password. The configured openid and the given password would become the HTTP basic auth to do updates to icecondor.com.
- the client gets a request token and sends the user with the token to the browser
- the browser goes to the server and asks to login (with openid), and approve the token. this also associates the token with a user
- the user is sent back to the client and the client exchanges a request token for an access token
- updates include the access key/pass (a token) with each update
This flow is based on the fireeagle app 'jfireeagle'.