Page tree
Skip to end of metadata
Go to start of metadata





Steve Thorpe


sys prog analyst

Tim Poe


sr. collaborative technologist

Paul Riddle


sr middleware architect

Michael Pelikan


information designer

Bradley Schwoerer


middleware technologist

Mark Scheible

NC State

iam architect

Eric Buchholt

LA Tech

iam architect

Doug Atwater

VA Tech

identity management

Jason Zylks


infrastructure services

Karsten Huneycutt

UNC-Chapel Hill

idm developer

Leo Howell


it audit manager

Steven Hopper


it director

Liz Wendland



Dustin Slater

U Texas-Austin

idm team member

Rob Carter


idm architect

Mark McCahill


collaborative system architect

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 - 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


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
  • No labels