[Openid-specs-heart] HEART AGENDA 2018-12-17

[Debbie Bucci]

*When:* Monday 1PM PST - 4PM EST
*Where:* GoToMeeting: https://global.gotomeeting.com/join/785234357
*US phone number:* +1 (619) 550-0003 <(619)%20550-0003>. Access Code
785-234-357
*Agenda:*

   - *Continue FAPI/HEART discussion*

2018-12-03 NOTES

*Attendees:*

·       Debbie Bucci

·       Justin Richer

·       Timothy Adams

·       Nancy Lush

·       Adrian Gropper

·       Eve Maler

·       Thompson Boyd

·       Tom Sullivan

·       Luis Maas

·       Nat Sakimura


Does it make sense to align HEART profiles for security with those that are
broader than health.


   - FAPI, although started specifically for Financial transaction is
   getting traction for to become no- sector specific.
   - IOT is horizontal - applicable to HEALTH use cases and may other
   sectors too.

Difference in FAPI and HEART (perhaps not that far apart)

·       HEART considers both read and right within existing profiles.  FAPI
has separated them out into different profiles and with stronger levels of
security for write.  (note SMART focused on read exchanges at the moment.)

·       Would be  interesting to look at the draft IETF standards/specs
that have been generated by that work JAR (
https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-17.html)  and JARM (
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-openid-financial-api-jarm-wd-01)


·       In references to token binding – mutual tls specifications – early
HEART version had looked at that approach

·       A bit difficult to compare side by side FAPI is writing using ISO
standards text - HEART defaults to IETF.   FAPI does appear to be written
in a way that requirements could be tested and referenced by number

Is it necessary to require OpenID Connect ?   Not always.  Would not use
for use case where identity information may not be needed or should not be
exposed.   Example – in Transferring money –  you do not necessarily want
to have ID information  included.

In Health IT there is interest in supporting dynamic client registration.
Can HEART do anything to promote client dynamic registration?  It’s already
part of the HEART specs.


   - The SMART team is beginning to talk about Dynamic registration and
   what may be needed.

UMA


   - User delegation – completely untouched by OAUTH in SMART at the
   moment. There nterest to introduce UMA for use in consent and delegated
   use cases.
   - Health IT SMEs are aware of the cross over between SMART and HEART.  There
   is interest in exploring further.   More conversations what is needed
   but it’s not a priority – just not ready to address.
   - There was an effort to introduce UMA at a  connectathon last year –
   but HL7 was not ready.   Patient Mediated concerns -
   Consent/Delegation/Dynamic registration are becoming an recurrent theme for
   these type of events
   - Some (developers- Health IT security SME?)  Are concerned about the
   Synch for science model.  Supporting an authorization code flow with
   resource token  lasting a year or more is worrisome.

Observation that the SMART profile may be falling short in support of
broader exchange – scopes are resource based in nonstandard way – at the
scope level.  Need for granular scopes and access control.  Scopes HEART
profiled in addition to those recognized by SMART may be useful.

Other topics

·       Specs currently not rendering properly.  Justin is looking into

·       Possible meet-up/meeting in Orlando?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20181216/ce7a18e3/attachment.html>