[Openid-specs-heart] HEART Profiles - OpenID Connect Certification

[Adrian Gropper]

This is a subthread specific to the OIDC Certification issues in the 3
profiles currently up for discussion.

I'm trying to understand the HEART profile for OAuth 2.0 has numerous
mentions of OpenID Connect including:
"The authorization server MUST provide an OpenID Connect service discovery
endpoint listing the components relevant to the OAuth protocol:"
as it relates to real-world implementations of an authorization server in
the context of the HEART Use Cases.

The OpenID Certification page http://openid.net/certification/ lists both
Google and MITREid Connect. The key difference seems to be that OP Dynamic
is not implemented by Google.

In the context of building a resource owner's authorization server like HIE
of One, the AS wants to make it easy and clear as it decides to add trusted
OPs to its OP whitelist.

Adding Google as an OP is certainly fussy. The steps involve access by the
RO to a Credentials Page on their OP as detailed
https://developers.google.com/identity/protocols/OpenIDConnect?hl=en This
is hardly a good user experience for a consumer that simply want to tell
her authorization server to trust Google as a source of user
authentication.

I presume that OPs that implement OP Dynamic such as MITREid Connect
improve the fussy Google user experience. Let's consider a hospital called
NPE (the resource server) that is willing to act as source of user
authentication for access to their HEART-compliant API.
1 - Alice (RO) would start by logging in to the NPE (RS) patient portal
2 - Alice would provide the RS with something like a URI or an email
address that enables the HEART-compliant RS to discover Alice's
HEART-compliant AS (HIE of One).
3 - Alice's AS would put up some kind of authorization form listing NPE as
a willing OP Dynamic identity provider for any provider that NPE is willing
to take responsibility for authenticating.
4 - If Alice approves, this authorization form, then NPE is added to her AS
whitelist of OPs.

If we're all together this far, we come up with some clarifying questions:

A - Why doesn't any well-known name on the OpenID Certified list implement
OP Dynamic?

B - If HIE of One could get the Django help we need to implement OP Dynamic
would the sequence 1-4 above be testable against healthauth.org with
(alice/wonderland)?

C - When RSs implement the HEART profiles as currently proposed, will it be
possible for Alice's AS to combine the authorization for NPE OP
registration and NPE resource registration into a single form such as:

[image: Inline image 1]
?

Adrian






-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151201/9a866442/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 180026 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151201/9a866442/attachment-0001.png>