the way i am envisioning the clients sending authenticated updates to the server is:

Plan A:

• 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.

Plan B:

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.

Plan C:

OAUTH.

• 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'.