When are the proposals due?

Proposals are due on May 31, 2013, 11:59 pm US Pacific Time (UTC/GMT -7 hours). Send them to admin@incommon.org.

Who will be reviewing the proposals?

InCommon/Internet2 have assembled a staff/community working group to assess the proposals. There will be representation from both the NSTIC Privacy/MFA grant and InCommon teams.

How do I keep current with what's going on with the RFP process?

Subscribe to ShibRFPInfo@incommon.org list by sending email to sympa AT incommon.org with subscribe ShibRFPInfo@incommon.org in the subject.

Use Case 1 Discussion

For use case 1, the assumption for the first configured option is that the user won't be confused by the static list, as they may be presented with options they can't use. This use case is best implemented in a simple authn environment where the authn choices are few.

Use Case 2 Discussion

For use case 2, if Sam was already authenticated as Silver and the SP requests Silver, the transaction is transparent to Sam (no additional login required) and IdP sends back Silver IAQ.

Use Case 3 Discussion

For use case 3, the user has an option to set up, but not step down in authn levels.

Slide 8: How should configuration be handled?

Follow current Shib conventions. Suggest you don't plug into the existing login handler because it will change a lot in V3. Spring?

Is a public github repo OK for this work?  We are interested in using github issue tracker and wiki as well.


Who will we be working with? Technical? Management? Would you prefer an iterative/agile approach?

Who: David Walker and Ann West. Approach: Either one works for us.

RFP references "using exisiting IdP data structures" for state management.  Does the committee have particular structures in mind?

All of the information required for the Multi-Valued Session Object is already maintained by Shibboleth.  Don't modify the existing structures, but you may have to compute some data on the fly.

RFP focused mostly on sunny-day scenarios, what about error/failure conditions?  

Use the existing APIs to communicate the error back to user. Not all is known about the error conditions and UI. Up to the bidder to think through this and iterate on it during the development process as issues come up. 

What level of integration testing is expected for existing login handlers? Can't use the existing login handlers.

We expect them to break with the new plugin. Defining new login handler interface is part of RFP. 

During the community testing and bug fixing phase, what level of support is envisioned?  

This is negotiable. We will be identifying 3 capable campuses to test the plugin, but at minimum we'd need an introduction call or webinar to orient the campuses on what they should be testing. InCommon would expect the bid winner to participate.  Support should be minimal other than addressing functional or technical issues that deviate from the RFP.

What does the committee have in mind for "Optional post-project support?"

Campuses needing support for Shibboleth v2 will need support for this plugin too. 

Is there flexibility in schedule start date/end date? Currently there is very little time between signed contract and project start.

Yes, especially if the code is clean and hits the right target. We are interested in getting this software finished and available to the community pretty quickly though.

When will we know we are done? RFP references acceptance criteria...will InC execute the tests?

The tests will be executed by three test campuses. 

Should we include community outreach in the proposal?  Identity Week presentation?

We do expect ongoing communication with the Shibboleth developer community during the project. However, the Shib Project has no right of refusal over the features and implementation. There will be presentations during identity week, so the bidder should be on notice that they may be asked to attend. 

What about compatibility with other version of Shibboleth?

Shibboleth 2.4 must be supported.  Support for earlier versions is desired but not required.  Proposals must indicate which versions of Shibboleth will be supported

Do the following 2 diagrams accurately reflect the requirements?

Note: The following diagrams were supplied by a potential bidder, not InCommon or Internet2. They should not be used as authoritative or as a true reflection of the requirements in the RFP. 

General Flow of Assurance Enhancements for Shibboleth IdP
- The authn context that the IdP returns is the one that the SP requests.

Shibboleth 2.x Idp Internal Authentication with Multi-Context Broker for Assurance
- May need rethinking given the existing login handlers will likely break.


  • No labels