[Openid-specs-heart] Draft HEART Meeting Notes 2016-04-11

[Sarah Squire]

Attending:

Debbie Bucci

Adrian Gropper

Sarah Squire

Thompson Boyd

Cait Ryan

Nancy Lush

Dale Moberg

Scott Shorter

Eve Maler

Glen Marshall

Jim Kragh

Luis Mass

Edmund Jay

Tom Sullivan

Jin Wen

Kathleen Connor

Scott:

Added a few terms to the wiki page from the specifications and use case and
provider directory workshop. I’ll get those into the glossary. If you go to
the HEART wiki page, recent activity shows the glossary, and I’ll email
this page to the group.

Debbie:

There was a provider directory workshop, and there was discussion about
using API rather that HPD, which is LDAP on top of SOAP. I’m wondering if
those are relevant to HEART.

Scott:

Anything that doesn’t need to be here we can remove.

Eve:

I’ve converted the UMA use case into markdown. Most of the text is the same
as before. I have been having conversations with various folks offline.
We’ve been talking about particular aspects of what the FHIR API would look
like if Alice wants to share with her husband in an interactive fashion.
There are a lot choices about provisioning the knowledge to Bob in some
fashion about what the resource is. That’s what we want to illuminate
through this use case. What would be the URL? Would it be a query? Would it
have Alice’s patient ID in it?

Debbie:

Is there some notice that is part of the flow?

Eve:

She’s not asked to share anything. It’s on her own initiative. I call it a
share button. That’s peripheral, but the fact that it’s of her own
initiative is core. Particulars of how it looks in an interface are
peripheral.

Adrian:

Is the share button on the resource server or the authorization server?

Eve:

It could be either. ForgeRock has it built into the authorization server
component, but you could build it in the resource server side.

Debbie:

You could be redirecting back to the AS even if you’re logged into the RS.

Eve:

When it comes to a notification, that is also a question. Does Bob get an
email? Does his app pop up a notification? Presumably that’s all going to
be peripheral. We don’t want to dictate how software writers appeal to the
market. Do we want to say something about the FHIR URL format?

Debbie:

Just thinking out loud: Alice gives Bob access, Bob needs to know Alice’s
AS, right?

Eve:

Bob’s client discovers Alice’s AS in the process of trying to access the
resource. Once I start writing the flows in this use case, I could outline
some of the UMA flows, but we could just reference back to the UMA spec. I
think I will not go into a lot of detail on those.

Debbie:

So we don’t think there’s a layer in front of that that’s doing
deidentification for Alice?

Eve:

The RS will have to be capable of exposing that scope in order for Alice to
be able to choose it. The RS is slicing up the data. Alice is saying who
she wants to get what. The AS is responsible for doing what Alice wants.

Adrian:

Alice is describing her policies only to the AS, not the RS.

Eve:

Right.

Debbie:

So what’s an example of a resource set?

Eve:

Resource set is a term of art for whatever the RS tells the AS is being
protected. For example, the thing being protected might be a folder with
many files in it. Only the RS knows that it’s a folder with many files in
it. The AS just needs to know it’s a thing that is protected. It’s a
“bundle” of things. It is equivalent to a protected resource.

Adrian:

Let’s skip to the simplest situation. The choice of policies to set are
made by Alice at the authorization server. Ahead of that, there’s a step
where Alice has linked the resource server to the authorization server.
That happened a day before? Or a second before? Is that an assumption we’re
making?

Eve:

We could treat it as peripheral, because either works. There might be
business assumptions about that.

Adrian:

Are we going to start out by picking one particular instance of a FHIR
transaction and follow the user experience from end to end? Or are we
generalizing?

Eve:

We’re looking at all the places that need profilable design patterns. Where
we can determine it to be peripheral, we should pick something and run. If
we’re not sure, we should discuss it in the group.

Adrian:

Wouldn’t it be easier if we started out with an index case first?

Eve:

I’m trying to come up with something that is close to the average of an
index case for different businesses.

Debbie:

How do we define how the RS tells the AS what it can protect?

Eve:

Given that FHIR already has a taxonomy of resources, that might be part of
our work.

Adrian:

Aside from the FHIR specific stuff, are we also profiling the format by
which the FHIR resource is communicated to the authorization server? Is it
XML? JSON?

Eve:

The authorization server doesn’t touch data.

Adrian:

How do we canonicalize communication about resources?

Eve:

The semantics around what to standardize will depend on the use cases.

Kathleen:

Hopefully we’re keeping track of how these standards interact with consent
directives.

Adrian:

I don’t actually know what a consent directive is. It sounds to me like the
default assumption for UMA is that the RS and the AS have constraints. We
don’t assume in UMA that Alice has more or less control over the resource
than the resource server.

Kathleen:

The institution can limit what Alice can do with that information. They set
up sharing policies.

Adrian:

But that’s not UMA. The basis for the AS choosing is of no concern to the
RS. FHIR should apply to all transfers regardless of whether an EHR is
involved. Policy is never communicated over the wire.

Kathleen:

How does policy get set if it never goes over the wire?

Adrian:

Alice’s policies are only known to Alice and the AS.

Kathleen:

We don’t disagree.

Eve:

UMA is not the only wire in question when it comes to access management.

Debbie:

If the AS needs to be aware of the resource sets and the policies, and the
AS is also aware of third-party access management stuff, it’s not the AS
that’s making the final decision. Right?

Eve:

The AS executes Alice’s wishes. It’s not acting on behalf of the
enterprise. It may or may not be the “end of the line” for access control.

Adrian:

I think if we can simply deal with the profiling and with the index case in
these terms, that’s what needs to be done.

Debbie:

Eve, how can we help? What’ the next step?

Eve:
Review prior to the next call would be great. I’ll send out the link to the
list.

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