*Participants*
Keith Hazelton, U. Wisconsin-Madison (chair)
Scott Cantor, OSU
Etan Weintraub, Johns Hopkins U.
Joy Veronneau, Cornell U.
RL “Bob” Morgan, U. Washington
Tom Barton, U. Chicago
David Wasley, Internet2
Michael Gettes, Internet2
Ann West, EDUCAUSE/Internet2
Renee Frost, Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)
New *Action Items*
[AI] {Keith} will propose specific edits to the eduPerson spec to cover the library walk-in value and will circulate for wider review and comments.
Carry-over *Action Items*
[AI] {Scott} will revise the pilot proposal to add an entry for attribute definition space. (18-Jun-07)
*Agenda*
1. Proposal to add "library-walk-in" to eP*Affiliation controlled vocabulary
* Expressing licensed resource eligibility via an affiliation < https://spaces.internet2.edu/x/2xI >
* The case for a scoped version of eduPersonEntitlement < https://spaces.internet2.edu/x/3BI >
2. Proposal to add "applicant" to eP*Affiliation controlled vocabulary
* C.f. excerpt from 29-June email from Joy Veronneau: "We are in the process of adding applicants to our directory over the summer. What we are worried about, and why I am starting this discussion, is access to Shibbolized resources. If the FAFSA site Shibbolizes, we would like our applicants to be able to sign in to that site with their Cornell applicant NetID. I'm assuming that eduPersonAffiliation and/or eduPersonScopedAffiliation might be attributes used by FAFSA? Or might they configure to use eduPersonEntitlement?"
3. Expressing level of assurance in InCommon - NIH pilots
* NIH Pilot Notes on Levels of Assurance <https://spaces.internet2.edu/x/EBQ >
*Discussion*
- Proposal to add "library-walk-in" to eP*Affiliation controlled vocabulary-
* Expressing licensed resource eligibility via an affiliation, < https://spaces.internet2.edu/x/2xI >
* The case for a scoped version of eduPersonEntitlement, < https://spaces.internet2.edu/x/3BI >
{Keith} has posted the two above documents as a result of discussion on the previous Working Group call. He heard back from the UK folks, who understood and accepted the idea that eduPersonScopedAffiliation would be one of the ways that a user could be authorized. This suggests that the problem can be addressed by adding library walk-in and eduPersonScopedAffiliation.
[AI] {Keith} will propose specific edits to the eduPerson spec to cover the library walk-in value and will circulate for wider review and comments.
The Group discussed various aspects around the scoping of eduPersonEntitlement. {Keith} views the string containing entitlement and institution related as follows: entitlement@institution (for which one holds the affiliation.) He said it would be easy enough to leave an unscoped attribute in an object class, but it would lead to a need for modification of the language around the current eduPersonEntitlement. There will also be a particular way of representing resources.
Some definition of eduPersonEntitlement is something you would not scope. While Entitlement is still needed in some instances, perhaps it should not be required. For example, not everyone at an institution may be interested in relating it to resources. How are embedded or cascading assertions dealt with? More so, “who” can say “what”? The Group discussed in detail the user of OU vs. scoped attributes.
- Proposal to add "applicant" to eP*Affiliation controlled vocabulary-
* C.f. excerpt from 29-June email from Joy Veronneau: "We are in the process of adding applicants to our directory over the summer. What we are worried about, and why I am starting this discussion, is access to Shibbolized resources. If the FAFSA site Shibbolizes, we would like our applicants to be able to sign in to that site with their Cornell applicant NetID. I'm assuming that eduPersonAffiliation and/or eduPersonScopedAffiliation might be attributes used by FAFSA? Or might they configure to use eduPersonEntitlement?" For more details, see: < https://mail.internet2.edu/wws/arc/mace-dir/2007-06/msg00046.html >
{Joy} further stated that their situation as it has somewhat evolved since her above post. {Scott} confirmed similar challenges at the OSU campus. Some believe applicants need to get a unique ID for each campus they apply to (respecting branding issues), which means that FAFSA would have to recognize all of the IDs for a single user.
The Group expressed interest in pursuing real world or real near future use cases to motivate spending to achieve progress in terms of how this is handled in a federated environment. {Bob} also pointed out that it is important to distinguish between the student applicant and the job applicant. Other important items to consider are lifecycle (i.e., as a prospect, student, then employ, etc.)
- Expressing level of assurance in InCommon - NIH pilots-
* NIH Pilot Notes on Levels of Assurance < https://spaces.internet2.edu/x/EBQ >
The Group briefly described level of assurance issues in InCommon regarding the NIH pilots. {Keith} said there was agreement to handle level of assurance of NIH at the Service Provider end (regarding level of assurance 1.) The Identity Provider would not have to handle it until distinguishing between Level 1 and
Level 2 applications. {Bob} raised a question about whether registered Identity Provider could be more than one level, and if/how it would represent additional burden to campuses, in terms of usability.
-MACE-Directory Wiki-
{Jessica} has created a Future List page in the MACE-Dir wiki: < https://spaces.internet2.edu/x/dBU >. Carry-over agenda topics will be posted here, and lingering Action Items with a lessened priority will be available here.
The next MACE-Dir Working Group call will be held on Monday, September 24, 2007 at 4:30pm EDT.