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