<div dir="ltr">
        
          <h2 id="markdown-header-roll-call-stats">Roll call stats</h2>
<p><a href="http://hg.openid.net/heart/wiki/Roll_Call" rel="nofollow">http://hg.openid.net/heart/wiki/Roll_Call</a></p>
<p>16 in attendance - 13 members</p>
<p>Listserv count : 98</p>
<p>IP count 30</p>
<h2 id="markdown-header-hub-use-case">HUB Use case</h2>
<p>Paul Grassi accompanied by Naomi Lefkovitz, from NIST/NSTIC presented
 the broker model use case  - base on the government’s Connect.gov</p>
<p>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. </p>
<p>SAML based architecture but OIDC on the roadmap.</p>
<p>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 </p>
<p>Issues with SAML</p>
<ol><li>Attributes send by are viewable by the broker</li><li>Attributes are across the wire, even when not needed, can add excessive data.</li></ol>
<p>Why can the broker see when using SAML? Trust is anchored at broker – broker removes crypto – then reapplies its own keys to RP</p>
<p>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.</p>
<p>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. </p>
<p>Historic reason for using SAML given it was a standard in wide use.</p>
<p>When there are bunch of servers/systems involved – there is much value in having a trust anchor – root or hub</p>
<p>Connect is a success in that they tackle the hardest step  - getting 
Government Agencies to externalize identity management functions</p>
<p>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.</p>
<p>When using UMA in the mix– authorization server kind needs to know who is the RP.   Blinding the user may not make sense.</p>
<p>For Connect - user gives consent at time they log in.  For some cases
 in HEART, consent is done asynchronously - user not present.</p>
<p>NIST/NSTIC and FICAM are hoping to lift and shift what ever comes out of HEART.</p>
<p>How does Connect extend  - when APIs are involved?  It has been 
prototyped how to do this over SAML – approaches are doable but not 
pretty.</p>
<p>Federal government privacy concerns take on completely different 
context – citizens are accessing multiple government services – crossing
 contextual boundaries</p>
<p>In Healthcare contextual boundaries and privacy concerns may be different and will be use case specific.</p>
<p>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</p>
<p>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.</p>
<p>In cases were identity is not necessary but just a trusted assertions about a subject suffice – hub architecture make sense.</p>

<p>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 </p>
        
      </div>