Assurance

[Ann West <>]

InterOp Testing Notes from 9/19

--------------------------------------------------

Jim Basney, NCSA

U of WI -  Milwaukee (Sorry UW folks. I didn't catch the names of all the folks in the room. If you send me your names, I can add them to the notes.)

Daniel Fischer - VT

Mary Dunker - VT

Martin Smith - UFL

Warren Curry - UFL

Renee Shuey - PSU

Scott Cantor - OSU

Tom Scavo - InCommon

Bob Morgan - UWash

Ann West - InCommon

Action Items

-------------------

Jim to set up SP for Use Case 0

Milwaukee/PSU - Chris Hubing/Possibly VT to set up IdP for Use Case 0

Jim to develop Policy use cases for SPs

Usual Suspect (Bob to delegate) to develop Policy use cases for IdPs

Ann to send out email to assurance list about InterOp use of the list

Ann to send out doodle poll for next call in October

------------------

https://spaces.internet2.edu/display/InCCollaborate/Assurance+Technical+Implementation+Issues

The group discussed a number of use cases that assurance needs to support and settled on the simplest for this first test: 

Use Case 0: SP requests Silver Qualifier and IdP returns Silver Qualifier. If the IdP doesn't have a Silver qualifier to return for that user/authentication instance, it will send an error. 

In general, Assurance testing (unless we find otherwise) would not be using attributes, but Authentication Context per the SAML spec: http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf. The group will then provide documentation for each use case as it does it's testing and include pointers to the SAML spec. In addition to InterOp testing, it is expected that Shibboleth software requirements will be generated from this work to enable richer Assurance support.

What version of Shibboleth do campuses need? You should use a very recent version of the IdP and SP, but implementations will still vary depending on how you're implementing Silver i.e. through use of directory attributes or different authentication systems. Campuses may need a  custom login handler at this early stage.

Why can't the IdP always assert Silver to any SP? In some IdPs, Silver is based on where you authenticate, not who you are. So if a campus has a two-factor authn system to support Silver, the school won't want users to use it for every SP. 

To help migrate services into a common framework, we should define a null assurance value, so that empty requests are not the common case. Requiring  "ordinary" as class would get folks going and at least asserting something. Campuses could also assert several assurance values upon the SP request---the order of the values matter in the process given the first one that matches is triggerable. 

The group will also start to document the policies/use cases need to be supported by Assurance Program. 

Next call second week in October.