tag:blogger.com,1999:blog-733074358901582680.post2590420559339820967..comments2024-03-23T05:28:35.472-04:00Comments on Healthcare Standards: A Four-legged OAuth for ABBIKeith W. Boonehttp://www.blogger.com/profile/16883038460949909300noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-733074358901582680.post-37872396629923963082012-10-31T14:15:51.393-04:002012-10-31T14:15:51.393-04:00A couple of responses:
1. As I mentioned previous...A couple of responses:<br />1. As I mentioned previously, Data Holder's don't necessarily want to become identity providers. Having to register an application with each data holder quickly becomes a ton of registrations. That means that data holders need to provide support to application providers to deal with various application connectivity issues.<br /><br />With regard to your other points: <br />1. We already TRUST client apps to keep their secrets. The apps I use today that use OAuth do so.<br />2. I reused OAuth transaction described in 2.1 of the OAuth RFC to deliver a key and secret to the client (in a way that is already done by OAuth).<br />3. I reused the verifier pattern in the second communication between client web-site and data holder.<br /><br />I'll have to look more deeply at OpenID Connect specifications. Right now, it isn't clear how these could be used by a Data Holder without the Data Holder having to be an Identity Provider.<br /><br />Also, I'm trying to avoid the million registration problem. To put it simply, if there are a 1000 apps, and a 1000 data holders, in order for every one of those apps to work with every one of those data holders, there must be a million registrations performed.<br /><br />Keith W. Boonehttps://www.blogger.com/profile/16883038460949909300noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-8703049624914817612012-10-31T13:34:42.843-04:002012-10-31T13:34:42.843-04:00Hi Keith,
Again thanks for bringing attention to ...Hi Keith,<br /><br />Again thanks for bringing attention to this issue -- but I'd strongly caution against inventing substantial new infrastructure here. <br /><br />Getting the details right is just very difficult. What do you see as the essential missing functionality, e.g., in the existing "dynamic client registration" draft for OpenID Connect [1]?<br /><br />Otherwise, two quick points:<br /><br />* A client app running on an end-user's device (phone, tablet, laptop, etc) probably shouldn't be trusted to keep a secret. Especially a secret on which the privacy of other people's data depends. (Imagine one rogue user extracting the app's consumer secret and running wild.) See discussion of public vs. confidential clients in the OAuth 2 spec [2].<br /><br />* As an example of the kind of subtlety involved here: the original OAuth spec was released and widely implemented when a session fixation vulnerability was discovered in its authorization process [3]. This was corrected in OAuth 1.0a by adding the `oauth_verifier parameter`. <br /><br /><br />[1] http://openid.net/specs/openid-connect-registration-1_0.html<br /><br />[2] http://tools.ietf.org/html/draft-ietf-oauth-v2-31<br /><br />[3] http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/Anonymoushttps://www.blogger.com/profile/14140643254419933279noreply@blogger.com