[Openid-specs-heart] Draft HEART Meeting Notes 2016-08-08

[Sarah Squire]

Attending:

Debbie Bucci

Adrian Gropper

Cait Ryan

Celestin Bitjonck

Danny van Leeuwen

Edmund Jay

Glen Marshall

Jim Kragh

Jin Wen

Justin Richer

Ken Salyards

Luis Maas

Mark Underwood

Nancy Lush

Oliver Lawless

Sarah Squire

Scott Shorter

Thompson Boyd

Tom Sullivan

Debbie:

When we say immunization.*, that could be a read or write, but if you’re
asking for patient consent, how does that work?

Justin:

Likely, Alice would register .read .write and .* and then clients could ask
for any of those three.

Debbie:

But the UMA AS could return .read even if the client asks for .*

Justin:

Right, and it’s up to the RS to enforce that.

Adrian:

When we look at the list of FHIR resources in a common clinical data set,
there are 39 scopes and 15 or so URIs.

Justin:

If there were 13 resources, there would be 39 scope strings

Adrian:

If we were to do this for all of the FHIR resources that are accessible at
a patient level, are we looking at a typical registration of a hundred
scopes? Or more?

Justin:

Sure.

Adrian:

We’ve talked about metadata associated with resources like confidentiality
codes and how that might play into scopes. How would the token be issued
for something that had a date range in it?

Justin:

Do you mean the range the token is valid? Or…?

Adrian:

It generally applies to the date of service.

Justin:

No one has come up with a definition for that yet.

Nancy:

Can we go back to just identify the resources before we identify
complications?

Justin:

The resources are the FHIR resources

Nancy:

Do we have to specify the read, write, or both?

Justin:

The intent in the specification is that the scope string be made up of
three parts - individual or bulk, the name of the resource, and the type of
action. That’s why it is three for every kind of resource.

Luis:

Lots of things get lumped into “observations” - vital signs, lab results,
etc. Is there a way to break that out and make it more granular?

Justin:

Often people think they need a lot of granularity in the security system.
OAuth 2 scopes are very simple and underspecified - it’s a list of strings.
That works. That lack of granularity works. There will never be a perfect
balance.

Debbie:

Aaron brought up immunization - typically there’s a URI associated with it.
You might get the URI but not the details.

Sarah:

To actually answer Luis’ question, that use case is not prevented by this
specification. Anyone can specify their own resources and scopes.

Adrian:

Should we define groupings of resources for user experience reasons? Or
should external entities define and publish groupings that they find useful?

Debbie:

I thought our profiles may have an example or two, but it’s up to the
resource server to create the resource sets. I don’t think it’s our role to
define those.

Justin:

It’s up to us to define what the HEART scopes are and what they mean, but
we don’t want to get into “special snowflake design.” It’s better to define
things based on the existing data structure - FHIR resources and types of
access.

Glen:

I agree. Our profile might be better to have a few exemplar use cases that
have an extensibility mechanism, so that if people want to add scopes, they
have a cookbook to do that.

Justin:

We don’t need to specify a recipe for extension.

Glen:

It can be very simple, but we should point that out.

Justin:

Good point. Feel free to suggest text.

Debbie:

For the semantic profile, are we going to have a few examples?

Justin:

We’ll have examples. We’ll also want to add text that says that we don’t
intend these to be the only scopes that are applicable to a system.

Debbie:

Maybe we could start with Eve’s use cases.

Adrian:

We have two clear cases on the table, let’s start with those. Are UX
considerations in scope?

Justin:

UX considerations are definitely in scope, particularly since we’re asking
humans to make security decisions.

Scott:

Is there a way to specify the semantics of your bag of strings?

Justin:

Yes, that’s what the semantic profile document does.

Adrian:

The first one would have to be the ROI form.

Justin:

We should be wary of the combinatorics of scopes of different natures. We
need to be careful that we specify that clearly in our profiles.

Adrian:

And the ROI form would force us to deal with that.

Justin:

But it doesn’t because it forces us to know the use case ahead of time. We
need to be able to deal with unknown use cases.

Debbie:

There could be a “general release” that would release all your data for
some security level or some sensitivity level. What would that look like?

Adrian:

I’m just saying that HEART has to enable solving this.

Debbie:

So where do we go next? I could see a resource server saying “here are all
my scopes” but that’s not a resource set.

Justin:

The set of scopes associated with a protected resource is an OAuth thing
that UMA inherits. I would like people to write down on the list, lists of
scopes and what they mean. For example, if you have a specific resource,
write down the scopes it would register. Also, what scopes the clients can
ask for and how those get mapped to tokens.

Adrian:

Would anyone’s use case be harmed if we had five scopes instead of three?
Add date range and confidentiality codes?

Oliver:

I think putting in the confidentiality codes implies system enforcement and
rules for that data, and that’s not what you’re trying to do with it.

Ken:

There’s the notion of a FHIR consent, so why specify confidentiality codes?

Justin:

We’re not assuming any global consent.

Debbie:

John was suggesting that FHIR consent isn’t ready yet.

Adrian:

Confidentiality codes can be set by the patient or by an organizational
process.

Debbie:

And the resource server would know how to process it.

Justin:

Resource servers don’t have to know how to process anything.

Ken:

It can opt not to support whatever it wants. If a resource server can’t
implement a consent directive, you don’t need to support one. The patient
can go there and specify what their policy is.

Justin:

There’s a difference between a consent directive and a policy engine.

Adrian has volunteered to demonstrate on the list a new scope design that
expresses the things he thinks should be expressed. I encourage other
people to do that as well.

Debbie:
I’ll send one to the list too based on intake.

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