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

[Debbie Bucci]

+1  Think we are all in agreement

Adding a conversation I had with Justin (thought I sent to list)


On Feb 29, 2016, at 5:09 PM, Debbie Bucci <debbucci at gmail.com> wrote:

>Justin

>Is this similar to some of the feedback in through Argonaut review of the
profile?  That is ...example .... EHR'S must support some functionality
that is outside the >scope of HEART so the common language we add may help
clarify there as well


Maybe, I think the Argonaut feedback is of a slightly different caliber but
it might get addressed by this. Proper scoping and framing is hard, and
important, regardless of reasons like this.

 — Justin



On Tue, Mar 1, 2016 at 7:40 AM, Moehrke, John (GE Healthcare) <
John.Moehrke at med.ge.com> wrote:

> 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_certification_&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.
>
> _______________________________________________
> 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/20160301/81403cf0/attachment.html>