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

[Moehrke, John (GE Healthcare)]

I support this. I had no idea that the HEART specs had conflicting
requirements. The advantages of using general-purpose OPs is huge.

 

Are the differences being driven by perceived risk? If so, then we could
certainly document the "Security Considerations" of the various realistic
options. That is to be clear about the risks, rather than just forbidding
something.

 

John

 

From: Openid-specs-heart
[mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Mike Jones
Sent: Monday, February 29, 2016 6:30 PM
To: openid-specs-heart at lists.openid.net
Cc: Anthony Nadalin
Subject: [Openid-specs-heart] 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/
<https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_certificatio
n_&d=CwMFAg&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT
_e9Lh49ujUftqzJ6q17C2t3eI64&m=44sr67wvOOdr3YwMx-ygTAgcEoMedGgza7iOSHpx-_Q&s=
5Pbz5S7kpEPHd-tKDbfuuNwWC83MtRk9hKE-NumwqkM&e=>  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-heart/attachments/20160301/8815fb47/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6966 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160301/8815fb47/attachment.p7s>