More Thoughts on OAuth2 Dynamic Client Registration in SMART on FHIR

Avinash Shanbhag writes:

---

Hi Keith

We had a question for you,  on your blog on “Dynamic Registration”, which I tried to post on the blog, but, somehow I don’t see it posted (Not sure, if you have ONC/HHS email filter on the commentsJ).

http://motorcycleguy.blogspot.com/2017/08/thoughts-on-oauth2-dynamic-client.html?utm_source=feedburner&utm_medium=twitter&utm_campaign=Feed%3A+MotorcycleGuy+%28Healthcare+Standards%29

==== Excerpt from Blog ==

Think about the fact that the application on your phone and the same application on your wife's phone, even though they are talking to the same endpoint, don't necessarily know about each other, and so if using Dynamic Registration probably get assigned separate client_id and client_secret values.

==== Upto here ===

From the above excerpt, it seems to indicate that each instance of App would get a separate Client ID/Secret. Is that really true? Our understanding is that the client ID/Secret is generated at the “App” level, same as any manual or self-service registration process would do;  and once done, the same ID (and secret if Confidential App) will be used by each instance of the App. So, in a sense, dynamic registration is no different than manual registration other than the obvious fact that this is done via API.

Here’s link to the SMART team’s web page that describes both the manual and dynamic approach

http://docs.smarthealthit.org/sandbox/register/

Could you clarify if we misunderstood your point, or if our understanding of the dynamic registration spec is wrong? If my post gets published, feel free to comment publicly.

Thanks in advance and looking forward to seeing you at the Interop Forum tomorrow!

Regards

Avinash

---

If this is the dynamic registration call (extracted from the link above):

POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: authorize-dstu2.smarthealthit.org

{
   "client_name": "Cool SMART App",
   "redirect_uris": [
     "https://srv.me/app/cool"
   ],
   "token_endpoint_auth_method": "none",
   "grant_types": ["authorization_code"],
   "initiate_login_uri": "https://srv.me/app/launch.html",
   "logo_uri": "https://srv.me/img/cool.png",
   "scope": "launch launch/patient launch/encounter patient/*.read user/*.* openid profile"
}

Here are some of the problems I see in it:

1. There's nothing in the above that allows me to trust the application registration content in any way.
   
   Anyone can use this same data to register an application.  The application itself runs on the patient's device.  If giving the same data gives back the same client_id and client_secret, then these items really aren't secret.  Anyone get the redirect_uri, the initiate_login_uri, and the logo_uri and the client_name.  How does one get these?  Build a FHIR Endpoint and ask the application to register itself against your endpoint.  It will gleefully tell you what it uses to register itself.
2. Knowing what an application uses to register itself, one can easily determine what client_id and client_secret is assigned to that application.
   
   This can be done by building an application that follows the dynamic registration protocol using the values extracted via the exploit I explain in #1 above.
3. There's nothing linking this registration back to a responsible party EXCEPT for an https: URL or three.
   
   I have 30 or 40 HTTPS urls I control, and all I needed was an email address to create one.  I think that providers need to take some precautions to safeguard healthcare data, and that means that there needs to be some way to trace it back to a responsible entity. That's a little bit more than what is required to create an https URL.  Also, not all redirect or login URIs would be to the Interwebs.
4. Use of token_endpoint_auth_method assumes public apps are supported (applications that cannot manage a client_secret), and that client_secret won't be used.
   
   I'd prefer to put a "somebody else's problem field" around application identity management if I could.  Otherwise, I have to deal with a lot more infrastructure that I want, but some identity providers barf at this today (you know who you are).  Either I have to use an identity provider that supports public apps, or I can restrict support to private apps.  The latter seems to be preferable given the infrastructure needed to manage application identities.
   
   In the example given, there's no reason why this application needs to be public, given that it's redirect and login URIs are "on the web".

So, client_id and client_secret, if created and maintained on a per-registration basis, needs something extra to ensure that you can safely consolidate multiple registrations to a singular client_id and client_secret for any application registering with the same information.  Otherwise, to have these values actually be an id and a secret that MEAN anything, you have to do more work.  What good is a secret if everyone can know it.

That's where I get into the "too much infrastructure" problem, because now we start introducing stuff like PKI to be able to verify publishers of software statements, or external trust bundles (a la DirectTrust or NATE or ...) and ...

Dynamic registration might be the way forward, but it doesn't appear to be ready yet for prime time.

   Keith