[Openid-specs-heart] Draft HEART Meeting Notes 2015-11-16 and HIMSS/RSA poll

[Sarah Squire]

Please take the poll and let people know if you're going to HIMSS or RSA
and would like to meetup with other HEART working group participants:


http://doodle.com/poll/zu3feshvn3kfdxav


Participants:

Debbie Bucci

Krishnan Iyer

Thompson Boyd

Danny van Leeuwen

Sarah Squire

Dale Moberg

Glen Marshall

Adrian Gropper

Eve Maler

Edmund Jay

Jim Kragh

Hope Morgan

Jin Wen

Adrian:

I’ve been trying to think of how to explain the different profiles that we
might create under HEART. The profiles can be categorized in these four
quadrants. There might be a consensus as to what order to do them in.
Starting in the upper right, a simple profile would involve no federation.
The lower right corner - the moderate profile - would apply to one patience
and the governance would be from an institution. The lower left is multiple
people with one institution. The upper left, a single patient is in charge,
but the resource handles many patients.

Sarah:

Can we clarify what we’re talking about when we say profile? We were
mandated with making five profiles, and we have drafts of four of them. Are
you saying we should review those?

Adrian:

A profile only makes sense if it drives interoperability. We also need to
talk about governance.

Eve:

The self-to-self sharing box is easy, but the moderate and very complex
boxes are really where we want to focus. How much do we want our profiles
say about the governance?

Adrian:

In my sequence diagram, the PCP and the PCP office are both just called a
non-person entity (NPE). It didn’t seem useful to separate the person from
the institution.

Debbie:

I did break them out because Alice can’t present in person to a system. NPE
was confusing for me. Having an NPE may be the simplest flow for UMA, just
to understand it.

Eve:

We are going to want to profile discovery and trust elevation. Imagine
there’s more than one patient in a system. How many authorization servers
are there? How do we want Alice to craft her policies? This is where
business models start to come in.

Debbie:

Argonaut is trying to get a handle on the OAuth flows, and UMA is a lot
more complicated, so if we can do baby steps, we should.

Eve:

Roland is working on implementing client libraries for UMA, and he’s
working off an attribute release policy use case. Picking concrete use
cases can help with business models.

Adrian:

I don’t agree that in terms of interoperability that OAuth is simpler than
UMA, it’s the opposite. If you look at it in terms of technology, yeah,
there’s a of complexity in UMA, but actual use cases, if your goal is to
specify interoperability, it’s better to start to UMA.

Debbie:

Is there a real-life use case for UMA that we can point people to?

Eve:

There are POCs in government. But we know we want to use it, so let’s get
concrete.

Debbie:

Adrian introduced another use case last week, and I’m making a sequence
diagram of it so that we can move on. I’m hoping we can do sequence
diagrams of each of the use cases. I think we have the core cases.

Adrian:

What are we going to do? What are we going to build? This sequence diagram
can be annotated with particular pointers to particular standards. In some
cases, we might find that UMA or OAuth doesn’t work that way. Then we can
find the gaps. We need input from the people who know the standards.

Debbie:

Does the consent receipt go back to the AS? I think it should go to the
owner.

Adrian:

I have the AS and the owner as being the same entity.

Dale:

Business models are interesting. Are all the use cases in the four walls
business model?

Eve:

It’s a good idea to look at our use cases and try to map them.

Glen:

Why not start with an existing profile on OAuth, such as IHE IUA (Internet
User Authentication)? See
http://wiki.ihe.net/index.php?title=Internet_User_Authorization It is
aligned with SMART on FHIR. It’s being tested in January.

Eve:

Twitter has a lot of third party clients, but they tend to have to onboard
in a fairly static way. It’s not “free love” or “total sovereignty.” So
Twitter is using the partner model, but OAuth is generally used in the
four-walls model. So if you use the Twitter client to access Twitter,
that’s an example of the four-walls business model. What you don’t see is
it ever used for number three. Now that we have dynamic registration, we
are starting to see it. But you can’t really get to full sovereignty.

Debbie:

What we originally wanted to do was we have three use cases we’ve talked
about a lot. We were going to do the business web sequence diagrams, then
the technical. If there are options to do it with OAuth or UMA, we can make
diagrams of both.

Adrian:

For each of those three, we have two subcases - the case where Alice’s
choice of AS is constrained, and the case when it’s not constrained. That’s
the difference between 2 and 3 that Eve was talking about.

Debbie:

That’s fine, but I do think we should limit it to these three use cases.

Adrian:

I’m willing to do a sequence diagram for the delegation use case. If
someone wants to annotate that with references to standards, that would be
great.

Debbie:

I can annotate the diagram I made last week to reference standards. Any
objections to going forward on this path?

Dale:

It would be nice to have clarity about use cases and business models.

Adrian:

There’s a hackathon at MIT this weekend. My goal is to create a reference
implementation of UMA that serves one patient as an authorization server.

Debbie:

How do we convince an end user that they need an authorization server?

Eve:

You don’t need to convince them, it’s just better than what’s out there now.

Adrian:

We just prompt the end user and ask them where their authorization server
is or make them a new one.

Eve:

It’s one of the reasons why business model one is so popular. It’s
analogous to one-property federation. Most people don’t know they’re using
single-sign-on.

Debbie:

I’m not going to HIMSS because I’m going to RSA.

Eve:
Maybe we should do a poll to see if we should do a BOF at either one?

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