[Openid-specs-heart] HEART Draft meeting notes 2015-04-15

Debbie Bucci debbucci at gmail.com
Sat Apr 18 12:53:28 UTC 2015


Roll call stats

http://hg.openid.net/heart/wiki/Roll_Call

18 in attendance - 7 struggled to listen on web meeting

Listserv count : 110 IP count 30
OpenID Foundation and OpenID Connect Conformance News

Don Thibeau opened with some news about the self-certification/conformance
program and the OIX registry. Eve commented that this is all part of the
“identity singularity”: things going faster and maturity happening faster.
Note Well

The Note Well was verbally given to the group by Justin
Introductions

We went around the room.
Argonaut

Josh gave the group a quick overview: In August 2014, this got started to
explore the next round of Meaningful Use -- the Meaningful Use Common Data
Set. It was about 18 specific elements. A call went out to the FHIR
community. People knew the schedule might slip. Members from the Federal
Advisory Committees (FACAs) kicked in some funding to mitigate that risk.
Six big vendors founded Argonaut through May of 2015 to ensure
authorization specs would be ready and possibly included in regulations
that were anticipated to come out around that time.

There was an idea to form an implementation community. There could be test
servers, sample data, automated testing, and so on. About 100 organizations
joined. Some details are still to be determined. Graham Grieve, core author
of FHIR, stood up some servers (?). The goal is to lay in some anonymized
patient data for testing.

There are still a lot of questions. Openness and transparency are the goal.
There’s a Google Group. There are monthly or every-six-weeks sponsored
phone calls that aren’t yet open to the public. The Argonaut sponsors don’t
yet know how this will play out, and transparancy still isn’t 100%.

Focus on 4 primary use cases Apps that can be run by patients or by
clinicians, and that launch inside inside or outside EHRs.

Debbie comments: At MIT, the MITREid Connect implementation, often used in
SMART demonstrations , has been extended to implement UMA (healthauth.org)
also available for testing.

Adrian would like to generate wide scalability across the network, in the
JASON sense.

Debbie describes ONC: It’s in charge of driving health IT strategy for the
nation and it's role in rule-making such as Meaningful Use. NPRM is Notice
of Proposed Rule-Making. APIs made it into the NPRM.

Josh fleshes out: ONC certifies what products have to do. When ONC said
that patients have to have access to health data through portals, that was
key. The mention of APIs was good, but it didn’t mention which API.

Debbie checked for good measure -
https://s3.amazonaws.com/public-inspection.federalregister.gov/2015-06612.pdf
-bottom
page 207 "... The intent behind this certification criterion is to allow
for, but not require, health IT developers to implement the Fast Health
Interoperability Resource (FHIR®) REST API and accompanying FHIR standard
..." A reminder that FHIR is just one API used for Health and there could
be more but for the scope of this effort we will focus on scope profiles
for FHIR as an exemplar as how we may create others as referenced below.
OAUTH Profile

Justin and Eve started walking through the OUATH spec using the layered
diagram.

We need to be certain that the core profiles are generic and separate
profiles for API specific scopes. Core generic profiles may cover 90% thus
the adoption curve should be much faster given both OpenID Connect and UMA
are built upon OAUTH

Some examples may be:

   - 42CFR part 3, HIPPA non HIPPA covered entities
   - payers/claims
   - Health IOT
   - research - discretionary era of health

We believe that Payer - claims vertical is in scope.

No experience to draw from thus a big effort for profile. Gather bits and
pieces together - best practices not know There have been small pilots.
Much had been defined to define pre/FHIR - OAUTH scopes for Hdata - BB+ for
limited FHIR scope. Argonaut security profiles- pulled what needed to work
end to end for their specific use cases.

Real difference between web and native may need another class Implicit
easier but less secure - designed for limited use case where app is running
inside browser running cross domain session server

Direct access - not delegate access -example HIE bulk transfers - back end
server communications Full/Direct - need to talk to OAUTH token endpoint -

client secret/password not allowed. We assume there is aREQUIRED higher
level of security - JWT - protected claims information - Key pair signed -
validate. JOSE suite - MUST

Note: Argonaut profile does use shared secrets - use authorization code
flow - do not use implicit. Has not considered the JOSE suite

confidential client public - all clients must authenticate

Debbie asked if client implementing Argonaut could register with a HEART
resource. The current answer is no. If server enforces HEART - will reject
non key pairs - client secret/password.

Debbie noted this is an issue that needs to be addressed. Justin suggested,
although not currently in the spec, there has been some conversation re:
the push of a key pair to a client.

Justin is adamant that key pair is necessary because it sets up a series of
other flows and functionalities as we move through the specs.

A good dialog between a number of participants (John, William, Cathy) and
others around Identity management related concerns, business approvals and
required processes such as Auditing. We need to determine what is in scope
for a profile. Some areas that perhaps are out of scope for inclusion in
the of profile - but will need to be detailed in the use cases or a best
practices. Perhaps some of this could be included in the binding
obligations. Debbie noted that the binding obligations sounded similar to
SAML AuthNContext. As the conversation was getting really interesting - we
ran out of time!
General

Huge thanks to our sponsors for the face to face -  Forgerock and OpenID
Foundation. To those of you that were on the web meeting for so long - we
apologize for the communication difficulties

Debbie will hand over the publishing of notes to the wiki to others so we
can get these out in a timely manner. (will post the March 30th and update
roster shortly)

*NO* meeting next Monday - many of us will be at RSA recap of sessions for
this that may be interested:

Adrian Gropper (P2P Privacy on FHIR group in attendance) Emergent Privacy
Models in Healthcare April 21, 2015 | 4:40 PM – 5:30 PM | West | Room: 3002

David Staggs (Joined by Eve) UMA in Health Care: Providing Patient Control
or Creating Chaos? April 24, 2015 | 11:20 AM – 12:10 PM | West | Room: 300

Eve Maler
On the Care and Feeding of Human and Device Relationships April 23, 2015 |
8:00 AM – 8:50 AM | West | Room: 3008

Use Context to Improve Your User Identification Odds April 23, 2015 | 10:20
AM – 11:10 AM | West | Room: 3009

Identithication: Convergence of Identity and Authentication - A Rock Opera
April 23, 2015 | 11:30 AM – 12:20 PM | West | Room: 2002

Debbie Bucci  Lock Your Front Door: Protecting Patient Portals April 23,
2015 | 11:30 AM – 12:20 PM | West | Room: 3006

Listing potential agenda items:

   - Wrap up OAUTH profile discussion - move to OpenID Connect
   - UMA Alpha spec
   - Trust Framework/Trust Marks/VoT/Binding Obligations
   - Consent receipt
   - Demonstrations of Reference implementations
   - Pilots?

Other topics of interest that may touch the HEART WG effort - please send
Debbie or Eve your suggestions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150418/1972dcac/attachment.html>


More information about the Openid-specs-heart mailing list