Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Wednesday, March 20, 2013

The Journey of 4000 Miles could have been 20

I don't know which is more amazing, that I may actually come back from Italy with a solution that may work to solve my million registration problem (which could just be a 10,000), that I had to travel 4000 miles to talk to a person who lives just 20 miles from my house (I've already walked that far this last week), or that the solution I may have coming out of an IHE meeting is clearly out of IHE's scope for its profile of OAuth 2.0 in IUA, even though it aligns quite well with other IHE profiles for security and privacy (I may write a post about that later).

Here's the solution in a nutshell:

  1. Application Developers obtain a certificate that enables them to sign other certificates.
  2. Application instances obtain (are provisioned with during or after installation) a certificate signed by the application developer.
  3. Application instances provide an attestation of their instance identity that is signed by the application instance's certificate in a normal authorization workflow that does not require a separate registration.

The authorization endpoint can verify the identity asserted by the application instance by verifying the signature of the identify assertion and the certificate chain. If an application instance misbehaves at some point, the authorization endpoint can be configured to reject the identity of that application instance, locking out only one installation. If a pattern of behavior appears where many instances of an application misbehave, the application developers certificate can be blacklisted, preventing any instance of that application from being authorized.

This is the level of security that has been deemed to be suitable for the ABBI PULL protocol. It allows a single bad actor to be rejected, and also allows all applications from a particular developer to also be rejected if deemed necessary.

The Direct protocol as specified by ONC already has a mechanism to white-list certificates through the Trust Bundle. The trust bundle is the collection of certificates that are considered to be trusted. A certificate chain is considered to be trusted if during the verification process, the certificate at the root of the trust chain (or earlier) appears in the trust bundle. This very same mechanism can be used by ABBI PULL to establish the chain of trust for certificates. It could be the same trust bundle as is used for the Direct trust bundle, but there are probably good reasons to keep these two bundles separate.

I was pretty close a while back, when I suggested that the application instance be provided with a signed identity assertion. What changes is that it is provided not with a signed identity assertion, but rather a signed certificate, which is nothing more than an signed identity assertion with the addition of a public and private key.

This is why I don't claim to be a security expert. I can understand this stuff when it is explained to me by experts, but couldn't have devised this on my own. Rob Horn (co-chair for IHE IT Infrastructure) was the person who did explain it to me, but he didn't invent the idea. It's the same mechanism used to sign Linux distributions from various suppliers.

The only difference in what I previously proposed (using a signed identity assertion), is in which certificate is used to sign the identity assertion. In this case, the certificate used is the certificate that the application instance is configured with. How this configuration is performed is completely under the control of the application developer, and becomes outside of the scope of the ABBI PULL specification.

The key to proving out this solution is whether I can make it work with existing OAuth 2.0 libraries, using signed identity assertions.

For what it's worth, the act of the authorization endpoint of verifying the signature on the asserted application identity is essentially the same as authenticating the installed application. So even when the implicit grant type is used, the application identity could still authenticated by the authorization endpoint.

Strengths:

  1. Reuse of existing "Trust Bundle" mechanism to support identification of "trusted" applications instead of trusted Direct addresses.
  2. Addition of client authentication even in implicit grant flows (by virtue of verifying signatures on the asserted identity).
  3. Simplifies Authorization endpoint responsibilities since they no longer have to be identity providers for applications, but can rather defer application identity management and provisioning to application developers, and use the signed identity assertions and a trust bundle to manage client authentication.

Weaknesses:

  1. Unproven with existing OAuth 2.0 libraries currently available.
  2. Doesn't follow the common used patterns for Twitter, Facebook or Google for OAuth 2.0.
  3. Use of an unproven and likely to be changed IETF Draft for JWT Bearer Tokens.

For a pilot, the IETF work seems to be close enough.  I'm not terrible worried about weakness #2, since that can be addressed by adequate developer documentation.  Also, when you are Google, Facebook or Twitter, conforming to what others do isn't necessarily part of your business model or concern.

That leaves weakness #1, which means I may have my work cut out for me. I just have to find a few OAuth 2.0 libraries to play with. Any thoughts on which ones I should look at (Java/JavaScript only please)?

As always, feel free to poke holes and deflate my currently inflated sense of accomplishment.

   -- Keith

P.S.  In trade for this solution, Rob got my entire text from the ABBI work on OAuth 2.0, in the hopes that he, as editor of IHE's IUA profile will find it useful.  In this, I hope that what IHE emerges with, and what ABBI starts with, eventually wind up in the same exact place, the IHE IUA  profile of OAuth 2.0.

6 comments:

  1. Keith

    Forgive me if I've missed the answer somewhere in your post, but would a working definition of "developer" (as you're using it here) include individual (human) application developers, software vendors (organizations) that develop HCIT applications, or both?

    TJL

    ReplyDelete
    Replies
    1. Thomas,

      Less either/or, more and/both. The distinction between an organization and a person becomes blurred because unless incorporated, a person is treated like an organization. The reality is that organizations AND individuals are developers, and that within an organization, an individual has to fulfill the necessary requirements.

      Keith

      Delete
  2. If I understand correctly, your proposal replaces "dynamic registration" with a centrally distributed "augmented" trust bundle (augmented to include not just app names + their certificates, but all the metadata that you'd normally need for OAuth client registration, including redirect URIs, names, ToS, contact addresses, etc.) Part of this trust bundle's job would also be to assign a single (consistent across all data holders) client_id for each app?

    I think bootstrapping registrations with a centralized bundle is great, as long as it's not a barrier to informed/intrepid patients getting access to whatever apps they want. (The implication here is that apps need a totally low-friction way to gain "low-trust" bundle membership, which may come along with patient-facing warning language at authorization time; and then a more robust vetting processes could enable membership in a "high-trust" bundle...)

    Re: JWT assertions, I'd still very much like to see a specification where public clients (including static web apps and mobile apps) don't need to jump through hoops to prove possession of a secret they can't properly keep. Specifically, I don't think the following is possible for static apps (with no persistent server-side component):
    "Application instances obtain... a certificate signed by the application developer."

    For confidential clients, I think JWT-based authentication is a great option, but client library support really is weak.

    ReplyDelete
    Replies
    1. Your second paragraph discusses what is a policy issue, rather than a technology issue. Addressing who creates/manages the trust bundle, how membership in it is established, and what it means with respect to degree of trust is really outside of the scope for S&I.

      Delete
  3. My goal in working with ABBI is to ensure a vibrant ecosystem of patient-facing health apps. This is cross-cutting (and it's not always easy to separate the technology from the policy). Some thoughts here:
    http://smartplatforms.org/2013/03/bluebutton-tech-and-policy/

    ReplyDelete
  4. Balliro Commerce Group offers premier design and development services.Boston App Developer

    ReplyDelete