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.

Justin

An error in the notes below: all members of the OpenID Foundation can vote, and voting is similar to the process in the Kantara Initiative. I think those thoughts got compressed and conflated.

Also remember that there’s a difference between being a member of the working group and a member of the foundation. If you didn’t pay a membership fee, you’re not likely a member of the foundation.

The two-week review period is for this working group only. Please send your comments to the list or to the issue tracker. Thanks!