HEART & iGov
Heart & iGov
Tuesday 1A
Convener: Justin Richer, Paul Grassi, Debbie Bucci
Notes-taker(s): John Fontana
Tags for the session - technology discussed/ideas considered:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Two new protocols at the OpenID Foundation
HEART and iGov
Heart is in health care patient centered use cases. Patient controls consent
iGov is working in gov. sector, citizen facing.
Justin is involved in both efforts.
there is some commonality but differences in the end goal
where do we align things are some of the questions
want to make what we do in Heart does not conflict with what we do in iGov, unless we make a conscious effort to split things.
I want it to be impossible for a dev to stand up a server at say IDP that is both heart compliant and igov complaint – they should at very least be compatible not directly conflict with each other . they should use lot of same constructs and requirements they should be able to cross reference at tech spec level.
Heart has draft protocls on the book now. Some things pulled from other places like Argonaut.
iGov just getting spun up– not a shell of a profile yet. Taking in legacy GSA profiles.
There is X-509 PKI stuff, saml and info card profile. blue button protocol from a few years ago fed in t HEART.
Green buton fed into iGov.
notion of clear button, pull out common aspects/ principles, there is some type of underlying structure here we might be able to get down to.
For HEeart, we have 5 profiles planned for HEART -
there are two profiles planned for iGov one for OIDC and Oauth
HEART set high bar for baseline security and interop
got rid of shared secrets, in heart all authN is based on asymmetric key pairs. Not x509 key pairs – that does not work. Using openID style infrastructure less PKI.
using RSA key pairs are currently mandated. All based on JOSE, you can do elliptical curve, RSA two flavors,
baseline interop,, proposing RS256 Jose method of sigs, be mandatory to implement. There is widespread support for this, crypto libraries and Jose libraries. the other point, this is not intro to heart session
other big piece of Heart security profiles beyond, is interoperability.
you have to publish the discovery end point. this is basic way to draw lines in sand to say this is what this is what needs to exist for people to more easily work together.
Mandating token introspection to enabling resource server with authZ server to work together. Mandate tokens issued are all signed JSON web tokens….Want them to be applicable across many deployments. Q: brokered or not brokered – is there issue with discovery not turned on?
NO
the other half of this is dynamic client registration, we have soft recommendation to enable for both oauth AS and Idp
makes a lot of sense in Heart case, ........may also make sense for gov side, but have to properly define context.
Heart. mandate dynamic client reg,, but we have a bit of text that sys you can decide scopes, types of clients. We many have stronger recommendations. Justin:
what is end state of the thing you are trying to do with this?
High level requirements Paul: selfishly we want these two profiles to have baseline security and interop and be in both, without having bunch of having gov use cases yet, I look at this at a peer to our saml profile. So baseline security , pricayc interop profiles and by the way, cross border use cases and we get to interop immediately.
you have hit on some of the other policy and technical hurdles., the time it takes to implement saml is ridiculous. We have some interesting attribute fundamentals that could be rationalized. Talk about threat models……
High level requirements
Heart ….Argonaut Debbie:
in beginning we had interop, if you did Argo and did Heart – there was no interop. it took lot of strain to get Argo to recognize H and vice versa. now that we are adding iGov, we don’t want to do that interop issue again. We want to avoid this
Justin: that is what we want IIW 15, to get out of this here. argonaut providers are just getting to understading oauth, they are struggling, they are doing username password. But we think this is a more secure connection. difference here is iGov does not exist yet. it is being se t up and standard building group to define how people interop in this space.
that is different from Heart and Argonaut, ie, picking names and values.
iGov is almost a clean sltae. But lot of legacy profiles and attribute bundles that are established.
heart if codifying what is already running
in Heart, setting things up so we have oauth 2. Profile… says if you are doing Oauth, this is what you have to do. on top of that is OIDC profile… it extends Oauth stuff. UMA is on top of OIDC – inherits from both of these; we have some FIHR scopes in use here and the last profile is FHIR UMA…
this is all built so you can break it apart – the FHIS side is health care specific on IGov side core it is oidc profile, it is about enduser ID and authN. Authz and policy management wrap nicely around this and it can all work together.
Question to OIDF is what can we do so we can minimize the drift between Heart and iGov? how much of this belongs in iGov and how much in Heart and can there be a neutral third party to do the basics.
proposal for moving forward. - Justin Richer
As igov starts we make make an explicit motion in igov to refer to the heart security profiles as the baseline an build on those – do that to start.
If it makes more sense for heart give that up ownership of those and have iGov work on those , we can make that move. If it makes more sense to converge, hope we don’t come to that, we can make that decision when we get there Paul:
I second, iGov has not had the international conversation. I hope common sense prevails.
