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.