[Openid-specs-heart] Draft HEART Meeting Notes 2016-09-12

[Sarah Squire]

Attendees:

Debbie Bucci

Adrian Gropper

Dale Moberg

Edmund Jay

Glen Marshall

Jim Kragh

Julie Maas

Kenneth Salyards

Luis Maas

Nancy Lush

Sarah Squire

Thomas Sullivan

Walter Kirk

Debbie:

Meeting is still on for September 19th.

MEETING CANCELLED on September 26th.



Sarah:

The UMA use case as it stands now (
https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR)
is extremely broad and talks about a lot of different scenarios. If we want
to optimize for interoperability (which I think we do) we need to
significantly narrow this document. I think it might help to write a few
short user stories - things like “Dr. Bob can request Alice’s current
medications” “Alice can reactively approve or deny Dr. Bob’s request.”

Smaller bite-size stories like this will make it much easier for us to
actually write the spec and make sure that the features we want are
possible in a wide-ecosystem cross-domain context without any requirement
for systems to agree beforehand on how to format requests across the wire.

Does that make sense?

Nancy:

I agree completely.

Debbie:

Is the suggestion to boil this down to smaller peices?

Sarah:

Right, shorter user stories that indicate specific features.

Adrian:

Do we need to discuss how Dr. Bob got the address for the resource?

Sarah:

We talk a little about that in the security profile, I think maybe we
suggest webfinger? We could certainly talk about it more in the semantic
profile.

Debbie:

Is there something we should start walking through?

Sarah:

My question to the group is whether there are things in this use case,
flows or functionality, that we don’t want to profile?

Glen:

I don’t think we should address discovery beyond recommendations. It would
be a significant increase in scope.

Sarah:

Agreed

Adrian:

But we do have to be clear about how we relate resource discovery to the
use cases that we present.

Nancy:

Let’s note that it exists and revisit it later.

Debbie:

Is there anything in the Data and Services section that we would take out?

Sarah:

We need to figure out which features and flows we want to enable and how
one server would indicate to another server which flow it is using.

Adrian:

Can we do the medications use case first?

Sarah:

It’s actually irrelevant which FHIR resource we talk about. We don’t define
the FHIR taxonomy. We are talking about features and flows that we will
need to enable.

Nancy:

We can use medication as an example, but we should be generic in the
specification as to which FHIR resource we are talking about.

Ken:

I don’t think it’s scalable to have a patient decide the policies on their
resources.

Debbie:

It will be much simpler in practice. I do think that a patient will be able
to say “share my medication list with Dr. Bob”

Sarah:

So, for example, we need to decide whether we want a proactive or reactive
flow or both.

Debbie:

So I think we’ve always said that consent and delegation are in scope.

Sarah:

So we’re looking at the “Summary of sharing scenarios” section of the
document. Do we want to profile all of these flows? We also need to profile
how claims are going to work. If Alice is proactively setting policies, she
will need to indicate what claims Dr. Bob has to fulfill before he gets
access to her resources.

Debbie:

I would also like to see a flow where Alice delegates access.

Sarah:

Are we talking about delegating access to data? Or access to the policies
themselves?

Debbie:

The policies themselves.

Sarah:

Okay, because there’s really no concept of that in the UMA protocol. It
would just be switching the Resource Owner.

Debbie:

So we can talk about that in the spec. Maybe just make it auditable.

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