[Openid-specs-heart] HEART specifications and their interactions with general-purpose identity providers

Justin Richer jricher at mit.edu
Tue Mar 1 00:48:58 UTC 2016


Hi Mike,

In reading the HEART profiles, I don’t believe this is true. The clients in HEART must use private_key_jwt, but the AS could support other methods for non-HEART clients. Non-HEART clients are out of scope for HEART, for obvious reasons.

Can you please point to the specific text that you believe contradicts this? It’s entirely possible that some text is currently misleading, as these are of course still in development as documents.

I am involved with an effort to develop a “HEART-mode” version of MITREid Connect which does turn off things like client_secret_basic at the AS level, so that *only* HEART clients can be registered. However, the plain version of the project should also be HEART compliant without the configuration parameter set.

Thanks,
 — Justin

> On Feb 29, 2016, at 4:30 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 
> 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/ <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.
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160229/0ea822cd/attachment.html>


More information about the Openid-specs-heart mailing list