meeting notes:
UW Madison
Federation used is to avoid credentialing everyone
why do we credential people?
- no credential at a federated party
- app that cannot use web authentication
- need to assert information to federated partners
- higher level of assurance
Can we get out of the business of credentialing some of our current audience?
What information do we really need to credential people?
Keith Hazeldon and others at UW have been look into this, see
wiki.doit.wisc.edu - search for affiliation review group
other reasons to credential:
- to establish affiliations
- to contextualize the affiliation - and an individual may have multiple affiliations/roles
examples: professor, councilor in a summer camp, collaborator in an cross institutional research project
how does level of assurance intersect with contextualized affiliation and roles?
- should level of assurance time out?
Penn state is building a collection of registries on a fairly granular level
How do you handle multiple affiliations?
- emeritus faculty or less loosely affiliated than prospective students
- systems of record may not have places to hold loosely affiliated people
- how do you differentiate people with almost identical data (and not much of it)?
Dustin (UT Austin)
- anyone can get a credential
- never de-active netIDs
- future, current, former affiliation slots are use to manage multiple affiliations
discussion:
best effort to tie these to unique people - tied by e-mail address
federation does not solve everything - prospective students are not necessarily in a federation
UT allows for some self-identification/joining of identities (if you know the login and password)
this sort of approach is OK as long as applications do not conflate authentication with authorization
this also implies that we need to contextualize the level of assurance from the federated partners when they make assertions about individuals
OpenID or Google do not provide high level of assurance
with global campuses we will never see some of the users - but may need reasonably high levels of assurance
affiliations are groups of people and we commonly use groups for authorizations
loose affiliation implies low level of assurance - and you may not have these people in your HR system
where is the system of record for these low assurance people?
very low assurance identities typically are really just containers for preferences
3rd party e-mail is typically needed for password resets - and this may be used as an identifier
note that sometimes people share e-mail accounts though
some institutions auto-expire these loose affiliated accounts
should there be an official extremely low level of assurance to pass in addition to the gold,bronze,silver?
how do these accounts get authorized for anything interesting?
what sort of identity proofing do we do for loose affiliation?
- use case: parents using student portal system
- parent is a "person of interest" in Peoplesoft with a birthdate
- claim a student by naming student and student's birthday
UT remote identity proofing
- notarized signature and photo sent it or copy of passport sent in
should community document the identity vs. authorization issue?
trust issue in federations
- what does "member" mean to an institution?
- can level of assurance be tied to attributes?
some sites are using protect network identities
- concerns about connecting these IDs to institutional IDs