> No, I meant the tokens which would be used if authentication is done with > https and > data transmission without. Somehow these two parts have to be connected, a > token transfered > with the authentication would be one solution. > > This token could be intercepted and used to send unauthenticated map data, > but only as long as the session lasts.
I think you misunderstand me or the process. My previous answer was exactly about the point you state here. If HTTPS is ever offered we have two options (as we do now): 1) Use the authentication mechanism that JOSM is using now: Sending the username and password with each request that requires it. This would mean that each and every request would have to be sent using HTTPS. 2) Use OAuth. While that requires a one time redirect to the browser on first usage it requires HTTPS _only_ when receiveng the Request Token + Token Secret and the Access Token + Token Secret. Each subsequent request to the API is done by constructing the request, adding the Access Token and _signing_ [1] the whole thing with the Token Secret. As both sides (JOSM and OSM) know the Token Secret but no one else (due to them being submitted via SSL) both sides can verify the requests authenticity. It does _not matter_ that the Access Token is send on each request as it alone provides _not enough information_ to make forged requests. OAuth in short with a description which steps would have to be secured by SSL: HTTPS: JOSM requests a Request Token from OSM and receives a Unauthorized Request Token and a Token Secret [2] HTTP: JOSM redirects the user to a page on OSM that asks the user whether he'd like to allow JOSM access to OSM in the name of that user. JOSM provides the Unauthorized Request Token for this redirect.[3] HTTPS: JOSM asks OSM (again using the Unauthorized Request Token) if the user has authorized the use. If this is the case OSM sends an Access Token and a Token Secret [3] HTTP: Every subsequent request is _signed_ using the Token Secret and that has always been transported securely and does not ever need to be send again This is quite technical but it works. I assumed a few things: - OSM switches to OAuth 1.0a, Matt Amos is aware of this and I believe it will be done eventually. He's done great work so far. I just don't know enough about Ruby on Rails - The Consumer Key and Consumer Secret provide no additional security here as they'd have to be stored in JOSMs source code And yes OAuth is implemented for OSM[5]. I don't know the specifics for Java but the whole OAuth process is generally very easy to implement for a client. A desktop client like JOSM would require some extra steps (redirect to external browser, ...) but it shouldn't be to hard. But until HTTPS is offered it doesn't really make sense to switch/implement it. Lars [1] http://oauth.net/core/1.0a#signing_process [2] http://oauth.net/core/1.0a#auth_step1 [3] http://oauth.net/core/1.0a#auth_step2 [4] http://oauth.net/core/1.0a#auth_step3 [5] http://wiki.openstreetmap.org/wiki/OAuth _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
