[Openid-specs-heart] HEART WG meeting notes 2015-03-23

[Debbie Bucci]

 Roll call stats

http://hg.openid.net/heart/wiki/Roll_Call

16 in attendance - 13 members

Listserv count : 98

IP count 30
HUB Use case

Paul Grassi accompanied by Naomi Lefkovitz, from NIST/NSTIC presented the
broker model use case - base on the government’s Connect.gov

Connect.gov uses common broker model for identity services. Connect is
privacy enhancing with brokering of CSP at the center. Minimize burden on
the RP – by simplifying the integration to a single endpoint.

SAML based architecture but OIDC on the roadmap.

Connect.gov uses double blind architecture but there is a desire to move to
triple blind. IDP credential does not have knowledge of the relying party.
Possible to be inferred via attributes to share but not disclosed. Typical
SAML flow- broker mediates everything

Issues with SAML

   1. Attributes send by are viewable by the broker
   2. Attributes are across the wire, even when not needed, can add
   excessive data.

Why can the broker see when using SAML? Trust is anchored at broker –
broker removes crypto – then reapplies its own keys to RP

Connect asks for attributes every time. Although because MBUN/opaque
identifiers are used, its difficult to determine if visit new/initial or
repeated. Risk for man in the middle attacks.

There was a proposal for JSON to handle triple blind but it was pushed to
the side due to the lack of a real use case to support it.

Historic reason for using SAML given it was a standard in wide use.

When there are bunch of servers/systems involved – there is much value in
having a trust anchor – root or hub

Connect is a success in that they tackle the hardest step - getting
Government Agencies to externalize identity management functions

SAML onboarding is heavy weigh. New protocols designed to be more
lightweight – less overhead. OIDC /OAUTH puts the user in the middle and
may present new ways to obviates the need of a broker. That said, 3rd party
verified Attribute providers – may still need broker to mediate. Connect
would allow users to provide their own attributes.

When using UMA in the mix– authorization server kind needs to know who is
the RP. Blinding the user may not make sense.

For Connect - user gives consent at time they log in. For some cases in
HEART, consent is done asynchronously - user not present.

NIST/NSTIC and FICAM are hoping to lift and shift what ever comes out of
HEART.

How does Connect extend - when APIs are involved? It has been prototyped
how to do this over SAML – approaches are doable but not pretty.

Federal government privacy concerns take on completely different context –
citizens are accessing multiple government services – crossing contextual
boundaries

In Healthcare contextual boundaries and privacy concerns may be different
and will be use case specific.

Maybe good for use cases such as Ring signatures – group signature Entities
to be trusted without giving away who the entity - all is known is that
someone from the group signed

Interchanges between two hospital and regulatory requirements may require
PII information to be shared. Doctor credential being used to prescribed
narcotics are optimizations around interconnecting through a hub – with the
intention for those transactions to be identifiable.

In cases were identity is not necessary but just a trusted assertions about
a subject suffice – hub architecture make sense.

Given the increased awareness of cyber-security citizen/patients may have
more confidence in federal agencies like the USPS that can provide a level
of enforcement. Unclear if this type of service would be equally assessable
to small parties/practices. Bit of a different controls themselves - if it
just a trusted assertion – we are pretty much there
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150328/de2fc3b4/attachment.html>