[Openid-specs-heart] Draft HEART Meeting Notes 2016-03-14

[Sarah Squire]

Attending:

Adrian Gropper

Scott Shorter

Sarah Squire

Jim Kragh

Eve Maler

Glen Marshall

Justin Richer

Edmund Jay

Kathleen Connor

Nancy Lush

Jeff Shultz

John Moerke

Dale Moberg

Terminology discussion:

The RPT is a “special snowflake” access token because of the hoops you have
to jump through to get it in UMA. In spirit, it is an access token.

It would be a good convention in the glossary to specify the source and/or
relevant protocol of the term in question.

Should we specify what tokens are not? Yes. In fact, NIST is moving toward
using “token” to refer to OAuth tokens, and “authenticator” to refer to
multi-factor authentication tools.

Eve:

I’ve taken an action item to make an “uma-flavored” version of our first
use case. We need to work more on the concept of the requesting party.

John:

You might want to look into FHIR consent.

Kathleen:

In the Privacy on FHIR work, if the requesting device wants an information
subset, we had to put it on a resource server. Patient directives would
then be encoded in the authorization server.

Adrian:

UMA doesn’t have to cover the “break glass” scenario.

Eve:

UMA is designed for a resource to be shared with somebody. I sent a “brute
force” method of specifying what the resource owner and resource server
wants so that it isn’t liable for what it shouldn’t be liable for. In
normal UMA, in limited circumstances, we should allow the resource server
to deny what the authorization server tells it to do.

Kathleen:

A FHIR audit event might be helpful to encourage correct action in those
cases.

Adrian:

We can build UMA on top of a notice mechanism.

Eve:

In terms of crafting a problem statement that is meaningful, the benefits I
would look for are consciously deciding who gets access to personal data
and being able to respond for requests for access. How do we solve sharing
with medical professionals? Do we use emails directly? What are the claims
that we ask medical professionals to present realistically?

Sarah:

But that’s out of scope for HEART. It’s up to the owner of the
implementation what claims they will require or accept.

Adrian:

Yes, but we need at least one use case.

Glen:

I just want something “good enough” particularly a reference implementation.

Eve:
I will take an action item to craft a problem statement.

Sarah Squire
Engage Identity
http://engageidentity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160314/c3261315/attachment.html>