[Openid-specs-igov] FW: HEART specifications and their interactions with general-purpose identity providers

Mike Jones Michael.Jones at microsoft.com
Tue Mar 1 00:35:44 UTC 2016


The note below about the HEART profiles is potentially relevant as we embark on creating iGov profiles.  Just like HEART should allow general-purpose identity providers to be used for healthcare applications, the iGov profiles we create should allow general-purpose IdPs to be used for government applications.  It's fine for the iGov profiles to require that additional functionality beyond the Basic OpenID profile be supported and for them to require that clients use this additional functionality.  But nothing in the profiles should prevent a conforming general-purpose IdP from also supporting the iGov functionality.

I hope that's a principle that we can all agree to on the call tomorrow.

                                                          Cheers,
                                                          -- Mike

From: Mike Jones
Sent: Monday, February 29, 2016 4:30 PM
To: openid-specs-heart at lists.openid.net
Cc: Anthony Nadalin <tonynad at microsoft.com>
Subject: HEART specifications and their interactions with general-purpose identity providers

Now that the HEART specs are Implementer's Drafts, I wanted to provide some specific review comments about some of the ways that the current HEART specifications relate to general-purpose identity providers.  The goal of these comments is to increase their adoptability by parties running general-purpose identity providers, which will be good for HEART overall, while still maintaining HEART's security and privacy goals.

There's a number of things that the HEART specifications currently prohibit supporting that are required to be supported in the OpenID Basic Profile.  This conflict means that general-purpose OPs can't current support the HEART specs, which isn't in HEART's best interest.  I know, for instance, that Microsoft wouldn't support them as currently written.  We would use our general-purpose identity providers for healthcare applications - not separate identity providers set up for only that purpose.

An example of such a conflict is that the Basic profile requires supporting client_secret_basic client authentication, whereas the HEART OAuth Profile prohibits its use.  This means, for instance, that none of the 20 identity providers that have been certified to the Basic profile at http://openid.net/certification/ could be HEART identity providers, even if they support the other functionality required by HEART, such as private_key_jwt client authentication.

This and things like it unnecessarily adversely affect the adoptability of the HEART specifications.  Fortunately, there's a simple solution to the problem.  The way out of this is to write the profiles in such a way that servers can be both general-purpose OPs and support HEART applications, whereas HEART clients can be restricted to only using HEART-specified mechanisms, such as private_key_jwt authentication.  Existing servers could be extended to support both Basic and HEART functionality - so that they can both be general-purpose servers and HEART servers.  HEART clients can restrict themselves to using only the HEART-specified functionality such as private_key_jwt - maintaining HEART's security and privacy goals.

I hope that the working group can agree to this principle as a basis for moving forward:  HEART can require that OPs support additional functionality beyond that required for general-purpose OPs, but will not require removing any.  HEART clients must use only HEART-specified functionality, even if other functionality is available.

Thank you for considering this feedback, which is intended to help make HEART more successful.

                                                          -- Mike

P.S.  I'll send detailed feedback on specific HEART specification features in a separate message, which I'll plan to get out in the next 24 hours.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-igov/attachments/20160301/6a3bc16d/attachment-0001.html>


More information about the Openid-specs-igov mailing list