[Openid-specs-heart] Draft HEART Meeting Notes 2016-07-16

[Sarah Squire]

Attending:

Debbie Bucci

Justin Richer

Celestin Bitjonck

Sarah Squire

Glen Marshall

Walter Kirk

Tom

Scott Shorter

Eve Maler

Kathleen Connor

Dale Moberg

Nancy Lush

Steven

Tom Sullivan

Jim Kragh

Jin Wen

Julie Maas

Adrian Gropper

Thompson Boyd

Debbie:

We were talking about the security tag in the fhir resource. Eve, is part
of the profile to do resource sets?

Eve:

I would say yes. There are dividing lines for what counts as a resource set
that we would want to profile.We should also talk about confidentiality and
security labels as opposed to the substance of the resource. John Moerke
has been pointing out the distinction between confidentiality and security.
Some information can be sensitive in some contexts, but not sensitive in
others. The type of record is orthogonal to its sensitivity. Security
labels have to be contextual. FHIR resource sets are based on type of
record.

Kathleen:

Security labels can be applied to resource sets. Laws require different
types of confidentiality to be attached to different types of resources.

Eve:

The type of content can be associated with a level of confidentiality, so
that information doesn’t actually have to travel with it.

Kathleen:

Right, you only put confidentiality labels on the lowest level.

Eve:

And if law changes in the future, you actually don’t want to send those
labels with the data itself.

Debbie:

What I think John was trying to say on the last call is that consent can be
an entirely separate transactions than the sharing of the information. The
confidentiality codes might be all you need. It might be something you do
on  class of data.

Kathleen:

Confidentiality codes are all you need to comply with the law.

Debbie:

So let’s start there. We’re almost doing a share button more than consent.

Eve:

If it is deterministic what types of information map to what types of
confidentiality codes…

Kathleen;

It’s very hard to do, but they have come up with a national set of clinical
codes. It’s a starting set. So we can do that, and it can be recognized.

Adrian:

What I think I heard from John is that they can get associated with a
protected resource by policy or by the patient.

Debbie:

A client can’t set a confidentiality code.

Justin:

How do we map this confidentiality code to Alice’s policies?

Kathleen:

Couldn’t we substitute security labs for scopes?

Justin:

We define a set of scopes that define the resources themselves. The best
way forward is to define a set of scopes that map to confidentiality code.

Eve:

That seems anomalous to me. What we have seems to be the difference between
mandatory and discretionary sharing.

Justin:

The processing of these permission still happen at the RS.

Kathleen:

Don’t client clearance scopes have to meet the scopes required?

Justin:

I think there’s an orthogonal vector of access control here. It’s talking
about a different kind of access rights. You’re describing all sorts of
different access rights in one field. It’s not “read write” it’s not
“allergy medication”

Debbie:

The confidentiality code is on the resource, so if you allow the client to
have high, you get that and below.

Justin:

Confidentiality codes are a piece of metadata on the resource. A scope is a
way to request a subset of right of access within the context of a given
transaction. The client can request a set of scopes. The AS can approve a
set of scopes. Those scopes get applied to the issued token. That token
gets handed to the client then the RS. The client isn’t asserting that it
has rights. It’s just saying that it asked and it has a token. These scopes
can represent a lot of things in the ecosystem. It’s perfectly reasonable
for them to be confidentiality codes or types of resource or level of
access.

Adrian:

If we were to use geolocation, we would single it out as a kind of
metadata. That’s what we’re going to do in HEART.

Eve:

There are things that are cross cutting across all scopes. They’re
different in nature.

Debbie:

Do you set the scope on the resource set?

Adrian:

There’s going to be a class of metadata that is standardized so clients can
declare whether they support it.

Eve:

I’m craving use cases and user stories.

Kathleen:

There were use cases like that from privacy on FHIR

Debbie:

To me it’s just another scope that gets passed in a token.

Eve:

Right now the client would be none the wiser because it doesn’t ask for
scopes.

Debbie:

So why can’t the authorization server use confidentiality as a scope? When
we’re focused on the FHIR API and confidentiality code is actually
populated.

Nancy:

I agree that we need use cases.

Eve:

If we could map to the clipboard use case, that would be helpful.

Debbie:

We could from the patient perspective declare a heart resource set that
everyone could comply with. Everyone could request the “clipboard resource
set”

Adrian:

Why shouldn’t we pick a specific release of information form and go through
that?

Debbie:
I think I finally understand. Defining of that form could be a resource
set. Let's work on starting with a clipboard resource set.

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