[Openid-specs-heart] Draft HEART Meeting Notes 2015-11-23

[Sarah Squire]

Attending:

abbie

Danny van Leeuwen

William Kinsley

Sarah Squire

Glen Marshall

Debbie Bucci

John Bradley

Eve Maler

Adrian Gropper

Thomas Sullivan

Josh Mandel

Edmund Jay

Dale Moberg

Justin Richer

Jeremy Maxwell

John Moehrke

Thompson Boyd

Implementers’ Drafts

Justin:

iGov is a new working group Justin is involved in. They are interested in
an interoperable set of security profiles for OAuth, OpenID Connect, and
possibly UMA. We have technical profiles for all three. These are all first
or second draft profiles, but they do have basic information about how to
implement these protocols to have out-of-the-box interoperability. Justin
proposes that we give these profiles a thorough scrubbing over the next two
weeks, and then publish them as implementers’ drafts, meaning they are
stable enough to try out. It doesn’t mean they can’t change, but it does
mean we would make a new draft if we made breaking changes. This would
allow people to start building systems that are “HEART compliant.” Making
these implementers’ drafts would mean that the iGov working group can
reference these for use in their projects. There is overlap between the
groups, so there will be coordination between the two.

John B:

To add to that, implementers’ drafts lock in people’s IPR contributions. If
you don’t want your contributions included, you would need to notify the
organization and withdraw from the working group. The process allows the
specs to be IPR unencumbered, i.e. it protects the implementers. Once the
group decides they are ready, there is a public review period, and then a
notification of the vote, then a voting period.

Debbie:

Who can vote?

Justin:

All members of the Kantara Initiative can vote.

John B:

Also the board needs to look at it and make sure it wouldn’t harm the
foundation in any way

Danny:

What about the non-technical people? What would you like from us in terms
of reviewing this?

Justin:

If you don’t feel comfortable commenting on the normative requirements,
just look through it and see if it makes sense. Better grammar or clearer
wordings are welcome. If anyone wants to edit the source xml, we’re happy
to take pull requests. Or you can just email your comments to the list. Or
you can add them to the issue tracker on Bitbucket.

Debbie:

Are you proposing that we take the next three weeks to look at each profile?

Justin:

I don’t want to take time on the calls to look at the profile. We’ve done
that. We just want people to look at them offline for the next two weeks.

Debbie:

So we would review until the 7th, and then open to public comment?

Justin:

Yes

Danny:

I think I’m a member, but how do I vote?

John B:

There’s a difference between being a foundation member and a working group
member. Being a working group member doesn’t require you to be a foundation
member. The working group has to come to consensus. The foundation members
have to vote. As the treasurer, John would recommend you spend the money to
join.

William:

Have these documents been updated to reflect discussions we’ve had since
April?

Justin:

Some of them have been updated, but the updates have been minor. Most of
the discussions we’ve had have not had relevance to these profiles. Those
would affect the semantic profile. If there’s something that needs to be
reflected there that hasn’t been, let us know.

John M:

My initial review of these is that these are vanilla without healthcare
specifics.

Justin:

If there are healthcare specifics, let us know because they aren’t supposed
to be in there. We made a conscious decision to separate everything
healthcare-specific.

William:

I’m concerned because when we talk about bidirectional PHR/EHR updates and
consent, those discussions involved things that would have to be modified
to support that.

Justin:

A lot of that is process around using these things, which is not a
technical profile. We can build the technology to support consent, but you
should not expect to see those in the base security profiles.

John B:

Process Doc
http://openid.net/wordpress-content/uploads/2010/01/OpenID_Process_Document_December_2009_Final_Approved.pdf

There is a 45day review process, and a 14 day notice for the vote. They can
overlap.

Debbie:

Can we ponder consent over the next two weeks?

Sarah:

I feel like consent doesn’t really fit well into the security profiles or
the semantic profiles. It should maybe be part of an additional profile, or
an extension, or just a detailed section of an implementers’ guide.

Dale:

Is there a potential interaction for OpenID Connect ways of doing things?
Claims and attributes? Or SAML?

Justin:

There’s a potential for an OIDC attribute profile talking about their
semantic meanings, but no one has brought up a need for it. SAML is out of
scope. You do get a jwt assertion as part of the OIDC protocol. Clients are
all authenticating using a jwt authentication assertion, but it’s just to
identify the client. It’s not a direct trade for an access token.

William:

In one of the use cases, we talked about single sign on. At the time, we
said that wasn’t supported.

Justin:

That’s just OpenID Connect.

Debbie:

This does set up the use of other claims, though, right?

Justin:

If there are specific claims we want to define as a working group, then we
might want to write a profile that determines those.

Adrian:

Unless we also work on actual code, this is all getting more complicated. I
would like to show a parallel path. I’m having trouble following the
expanding branches of what’s in scope or out of scope.

John M:

We used jwts and SAML because we were interoperating with people who wanted
that. I agree we shouldn’t go there at this point.

Justin:

In OIDC, attributes are released per-transaction rather than per-client.

Debbie:

Would you have an attribute bundle in an OIDC world?

John B:

In some way, attribute bundles are scopes. They’re an easy way of referring
to these things. I don’t think that’s a problem.

John M:

The closer we can be to only inventing for healthcare things that are
specific for healthcare, that is best. These security profiles are void of
healthcare specifics.

Glen:

The notion of what is healthcare and what is not is a very flexible thing
that has evolved over time. At one point, saying we should include devices
like Fitbits, we said we should not include it because it’s not healthcare,
but now we see that it is.

Debbie:

I think we’ve expanded from “heathcare” to “health”

Debbie:

So we’re still going for implementers drafts.

Justin:

You’ve got two weeks. Please do not email me directly. You can view the
revision history in the repository.

Debbie:

Are the rendered versions up to date?

Justin:

The source files in the repository are the most recent and you can view
their version histories. They have not changed since April.

Adrian:

I will present next week. I think these things should happen in parallel.
Starting last weekend, we put up code for a generic personal uma
authorization server on github. I’d like to demo what we’ve done so far. We
took the annotated sequence diagram and turned it into a django demo
sequence by sequence so there are screens with code behind them for all 22
steps. So it’s basically a framework for building this thing. It is scoped
specifically to the first two use cases.

William:

Justin, what would you say is the top contributions that came from this
group on what we have now?

Justin:

It all depends on what your area of expertise is. If you know the technical
protocols and specifications. If not, make sure it’s not precluding any
functionality that you think is critical.

Debbie:
When I was doing the business sequence diagram, it was clear that to go to
the next step past these profiles would be helpful.

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