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

[Sarah Squire]

Attendees:

Debbie Bucci

Adrian Gropper

Cait Ryan

Celestin Bitjonck

Glen Marshall

Jin Wen

Josh Mandel

Justin Richer

Kenneth Salyards

Luis Maas

Nancy Lush

Sarah Squire

Scott Shorter

Tom Sullivan

Walter Kirk

Debbie:

I’ve been pasting pieces together from what I wrote and what Eve and Nancy
have been working on. What I need feedback on now is proactive vs reactive
flows and whether we want to have UX requirements for those.

Glen:

I’m concerned about having the UX as part of the profile. That seems like
it would be out of scope. That’s really talking about the how, not the what.

Debbie:

So let’s take out the UX portion, and just talk about policy requirements

Justin:

Another reactive flow would be Alice delegating to herself

Debbie:

What about the introduction of the AS and the RS to each other?

Justin:

In the technical profile, we require that the AS allow for dynamic
registration and discovery and that the PAT be made available through an
interactive OAuth flow.

Glen:

I tend to think of security as a layered approach with different functions
in the different layers. So we have authentication at a lower level, and
policy at a higher level. I’d like to go through this document from a
layered approach.

Nancy:

Under purpose, does that need to be included in the authorization?

Debbie:

So does the AS ever send claims to the RS?

Justin:

Not normally, but it could supply them in an introspection response.

Debbie:

So how does the RS tell the AS what policies and claims are required?

Sarah:

It doesn’t. Alice registers her resource with the AS and sets her own
policies and claims requirements.

Glen:

I see this work as happening out of band.

Debbie:

But how do we do it at scale out of band?

Glen:

The authorization server may have to redirect to a rules engine for some
more complex determinations.

Luis:

How are we proposing that the resource server knows that it’s Alice?

Justin:

The way the resource server knows who Alice is is completely out of band in
the UMA spec. We can specify that in HEART we have to use openid connect
and record binding protocols, but it’s going to be system specific.

Luis:

I don’t think we should assume that the AS has any idea who is accessing
the data.

Justin:

It’s not Alice, it’s Bob who is accessing the data.

Sarah:

Alice does need to be able to login to the AS in such a way that we can
know that she’s the same Alice from the RS, and not Eve attempting to set
policies on Alice’s resources.

Debbie:

So Bob needs an account at the AS?

Sarah:

Bob needs claims

Justin:

Right, so Bob might have a verified email address, or a code that Alice has
given him.

Debbie:

Should we implement user-friendly names?

Nancy:

I think it’s too complicated for a first pass once we get into it

Josh:

FHIR was designed for health technologists, not normal people. In Sync for
Science we’re not trying to map FHIR resources one-to-one, we’re just
trying to take entire sets of data.

Nancy:

I suspect that in most cases, Alice is going to choose “all.”

Adrian:

Does sync for science allow for sharing with exceptions?

Josh:

No, but each individual vendor has their own logic for exceptions. All
vendors support access to the entire data set. Some vendors allow the
patient to scope that down, but that’s all under the hood. We don’t try to
standardize that process.

Adrian:

Do we want to profile how HEART notifications are sent?

Justin:

That’s completely out of scope.

Glen:

It seems like a URI would be the only way to do that.

Justin:

At some layer it needs to be a URI, but the notification to the person
wouldn’t necessarily involve that.

Adrian:

Do we need to obfuscate the patient ID?

Glen:

Not for a first pass. HIPAA does not consider a patient ID to be pii.

Adrian:

What about ways to verify claims?

Justin:

Only the AS will verify claims

Adrian:

Do we need to profile semantics for claims?

Justin:

We are in a good position to profile claims. The UMA spec is very
open-ended on this point. However, we shouldn’t disallow other claim
formats and types.

Debbie:

What do we need to move the profile forward?

Justin:

We need consensus around what to do about claims semantics and resource set
types. That’s the next step to get something on paper.


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