Medical Middleware (MedMid) WG Call Thu 11-August

*Action Items*
New
[AI] Anyone interested in testing the feasibility of inter-institutional collaboration on courseware via Shibboleth please contact Dave Damassa <david.damassa@tufts.edu> [AI] Comments on the VistA program, especially related to identity and access management middleware, are encouraged. Please direct them to the list. (See mail from SteveO to the list 22-July-05 for related links).

Carryover
[AI] {SteveO} will follow up with Keith about the AAMC identifier proposal. [AI] {Keith} will post a note to the MACE list inquiring about MedMid related activities in Europe.

*Participants*
Chad La Joie, Project Sentinel Collaboratory, Georgetown U.
Brent Putman, Project Sentinel Collaboratory, Georgetown U.
Dave Damassa, Tufts U. Mike McGill, Internet2
Keith Hazelton, U. Wisconsin - Madison
Ann West, EDUCAUSE/Internet2
Renee Frost, Internet2
Steve Olshansky, Internet2 (stand-in chair, scribe)

*Discussion*
As no one on the call was very familiar with the VistA program (Veterans Health Information Systems and Technology Architecture), this topic was deferred for a future call.

Pilot Update: Project Sentinel Collaboratory:
They are evaluating PERMIS as a possible solution to a concern that has arisen with one of the participant organizations, which is currently not addressed to their satisfaction within the Shibboleth system. Specifically, they don’t trust other organizations to assert attributes that they themselves don’t directly assign, and would be used to grant access to medical data.

Fundamentally, the service provider (SP) wants to be able to ensure that the attribute they are receiving about a requesting user or system, which is used to make an informed decision about whether to grant access to the resource(s) being requested, is what the Identity Provider (IdP) System of Authority (SoA) actually issued and that it hasn’t been altered. Put another way, the SP doesn’t trust the IdP Attribute Authority (AA), and thus needs to be able to verify the attributes being presented. In a complex system, with the potential for multiple AAs providing various attributes about a user, the need to be able to and verify the assertions themselves becomes more prominent.

This sort of use case (multiple AAs holding and being queried for various user attributes) has arisen in other contexts, e.g. in the case of a user who is affiliated with an institution and who is also a member of IEEE. If s/he requests a library resource, s/he may be entitled to deeper access based on their IEEE affiliation, and that attribute would ideally need to come directly from IEEE.

PERMIS' use of X.509 attribute certificates (ACs) would seem to be a good solution, and the Project Sentinel development team is in communication with the PERMIS project on this subject. PERMIS allows the identity provider (IdP) to create an AC for a person, give it to that person who can then upload it to their local ID store, then use Shib to transport it to the SP as part of the access request. The SP can then verify that the IdP is in fact the organization that issued the AC, that it is the correct attribute - in essence binding the SoA to the attribute.

This same functionality could likely be accomplished natively within the Shibboleth system with some work, but PERMIS appears to present a good alternative.
http://www.nmi-edit.org/releases/index.cfm#PERMIS

Another issue which has arisen is that hospital affiliates are concerned the about lack of IdP session destruction, i.e. a user cannot cleanly logout of a session. There is a possible solution being explored for inclusion in a later release of Shibboleth, but a non-SAML compliant work-around could be available sooner.

Project Sentinel Federation development efforts are underway. They have a CA and WAYF operating, and metadata defined. Policies and practices are not defined. yet. When they reach that point they will likely look to the policies and practices developed for the InCommon Federation as a model, but will probably need to be significantly more specific in a medical context. The question arose of how their nascent federation  would relate to InCommon in the future - peering? This is new ground being explored,  and will be interesting to observe as it develops. There are federation peering discussions underway at the international level, and as new federations appear in the US this issue will come to the fore. One possible model could be using InCommon as a foundation with additional features to support specific needs - layered concentric spheres?
    http://www.incommonfederation.org/

The U. Texas federation is another model to observe as it develops, their documents are expected to be available as well when they are ready.

Pilot Update: Tufts University / TUSK
They are making progress, Shibboleth v1.3 IdP is up, the v1.3 SP (TUSK) should be up and running in a couple of weeks, and they are actively looking for partners interested in sharing medical course-related materials in an inter-institutional collaboration - not clinical data. Tufts is partnering with the MIT OpenCourseWare (OCW) initiative, sharing some of their non-proprietary course material for public access via OCW.
    http://ocw.mit.edu/

[AI] Anyone interested in testing the feasibility of inter-institutional collaboration on courseware via Shibboleth should contact Dave Damassa <david.damassa@tufts.edu>

As a final note, caBIG will be meeting soon in DC, and one of their key focus areas will be security requirements. They appear to be interested in exploring the applicability of the 3 key software development projects of the Internet2 Middleware Initiative – Signet, Grouper, and Shibboleth – to their specific requirements. They have also expressed interest in the Secure Access For Everyone (SAFE) program.
    https://cabig.nci.nih.gov/
    http://www.safe-biopharma.org/

The next MedMid call will be Thu 8-Sep 2:00 EDT (2nd Thursday of the month). Agenda and bridge info will go out to this list in advance of the call.