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

[Sarah Squire]

Attending:

Debbie Bucci

Adrian Gropper

Cait Ryan

Celestin Bitjonck

David Batchelor

Edmund Jay

Eve Maler

Glen Marshall

Jin Wen

Julie Maas

Justin Richer

Kenneth Salyards

Luis Maas

Nancy Lush

Sarah Squire

Scott Shorter

Steve

Walter Kirk

Debbie:

Let’s discuss what may or may not be in scope for Adrian’s recommendations
to the list. Would someone please explain to me a software statement?

Justin:

Software statements are defined in the IETF OAuth Dynamic Registration
specification. The idea is that clients carry signed documents with them
when they register with an OAuth authorization server. This document
contains metadata and proof of approval from some organization.

Debbie:

So an app will use a conformance statement to prove that they are the app
that they are? As opposed to providing a software statement?

Justin:

The point of the software statement is to prove that you are who you say
you are.

Adrian:

A conformance statement is signed by whoever created the app. A software
statement is signed by someone trusted who approved the app.

Justin:

A software statement isn’t just a statement, it’s an assertion. A
conformance statement is more general.

Debbie:

So there’s nothing that indicates what protocols are supported?  And how do
we ensure the cybersecurity of the app?

Justin:

Remember it’s the patient’s choice to release information to an
application. That’s why we mandate dynamic registration.

Adrian:

How does the RS decide whether or not they need to warn the resource owner
- the patient - separately from the authorization server?

Justin:

They don’t.

Adrian:

That’s inconsistent with the API taskforce outcome.

Glen:

This whole matter is nonregulatory - it’s a recommendation, and it doesn’t
do anything to get us closer to implementation.

Debbie:

I think it’s an implementation choice that has nothing to do with HEART.

Justin:

The recommendations that Adrian is citing have nothing to do with the RS
and AS as we are splitting them up in our recommendations. The RS is
generally thought of to be both the API and the components that protect it.
It’s very much within the recommendations that the provider of the
information needs to notify the user, and we do that through the
authorization server. If the authorization server is outsourced, the
notification is also outsourced.

Adrian:

At the last UMA meeting, the VA folks presented their potential solution
that they call cascading authorization servers. They need to have some
visibility on the part of the resource server when the resource server is
the VA. This is a primary issue. HEART says that they AS can be built, run,
or outsourced. Here, because the AS is built, there’s no trust relationship
for the VA to take into account.

Debbie:

So when we talk about the UMA flows, we talk about proactive and reactive
flows. The reactive flows require user input. Is that part of the UMA
profile? Or is that out of scope?

Eve:

The UMA protocol says almost nothing about these flows. A reactive flow
could be done in many different ways. But we’ve decided not to give UX
guidance, so it’s an implementation decision.

Justin:

If the protocol specifically calls for interaction with a human being, we
can talk about that in the specification.

Debbie:

So the purpose of the software statement - is it possible that the software
statement is insufficient so that it could trigger an out of band response
from the resource owner for approvals?

Justin:

The software statement is about the identity of the client. If that can be
used to make other decisions, that’s fine, but that’s not the only kind of
decision that the AS is going to make? Compliance with sharing policies
have nothing to do with client registration.

Debbie:

Could that be suggestions and guidance? Or is that out of scope?

Justin:

That’s out of scope.

Debbie:

So Adrian’s concern could be addressed in implementations, but it’s not
something specific that HEART needs to address?

Justin:

Right

Glen:

Agreed

Adrian:

Whatever we decide needs to be documented in such a way that it reflects
the concerns of the VA and the real-world issues they are concerned with.

[Eve presented a draft proposal for UMA+FHIR resource set registration
profiling]

Justin:

Star stands for read and write today, but the intent was for it to
represent read, write, and any other scopes that an individual API might
dictate. One of the problems with things being compounded as they are in
the OAuth profile is that you need to list them all out.

Eve:

It’s probably a good idea to figure out what the best practice is and stick
to that.

Justin:

We definitely want things to be able to offer additional scopes and still
be heart-compliant.

Eve:

The user access policy uri property is something I wanted to flag. The idea
is for the RS to allow deep links into the AS interface. HEART probably
shouldn’t require or ban that. It should probably remain optional. Maybe
better to say nothing? We also don’t say that just because you registered
something doesn’t mean that you have to be a FHIR server, you just have to
conform to FHIR standards in serving data of that type. You can serve
resources that aren’t FHIR compliant as well.

Debbie:
I don’t think we’re going to have a HEART meeting the next two Mondays. The
ninth will probably be the next meeting.

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