Assumptions and Notes about InCommon Silver Compliance

Please insert sub-bullets for any assumptions or other observations about your campus's InCommon Silver compliance that you feel would be of interest to other campuses.

• UCB
• UCD
• UCI
• UCLA
• UCM
• UCR
• UCSD
  • “…the Subject shall identify himself or herself in any new transaction (beyond the first transaction or encounter) with information known only to the Subject…"
    • My concern is just how secret does the secret have to be to assume that only the Subject knows it?  They mention a temporary secret as an example, either established during a prior transaction or sent to the address of record, but clearly e-mail administrators could learn the secret when sent via email or the registration agent might be able to see the temporary secret during registration.  Is it even possible to meet this requirement as stated?  It seems that at the very least, a system administrator could read the secret from memory as it is established.
• UCSF
• UCSB
  • Approach and Assumptions
    • We are defaulting all local identity to so-called Bronze level. Silver level requires an uplift process for those demographics that are eligible for silver.
    • We are not questioning or evaluating any externalities such as PPS or student registration. From a business perspective, they are completely separated from IdM and we are logically required to assume that other units within the university follow their published policies and practices.
    • We are undecided as yet on one ID and two passwords, or two IDs and two passwords. Our current engineering does not preclude either.
    • We currently require employees to present themselves in person at the Identity desk even after an I-9 verification. We are hopeful that in the forthcoming PPS/HRIS replacement project we will be able to tie it to the creation of identity within the IdM, and thus eliminate the second in person verification of credentials.
• UCSC
  • General Questions
    • Is there an assumption that when we assert a givenName/sn for a Subject with a Silver IAQ that the name we provide is the name on record? (E.g., "legal name" and not "name I like to be called")?
  • Define: Registration
    • I assume that "IdPO Registration" refers to the process of creating a new identity/person record in whatever system is the source of that record. So for UCSC, the Registration is the entry of a student record into the student system, of an employee record into (one of) the HR system(s) or of a "sundry" record into the IdMS itself.
  • General IVP Questions
    • In many cases we generate and distribute credentials "in advance", without much identity vetting, and then later do an identity vetting of the individual. E.g., we create an account for a Subject with an informal employment offer (who is not in PPS), provide the (presumed) Subject with the credential, and then later do an in-person or remote verification of the Subject (I-9 verification, entry into PPS).
      In these cases it's difficult to assert that the person we originally distributed the credential to is the same physical Subject as goes through the IVP, since there was no real IVP (at least not beyond Bronze level) of the initial, non-validated credential distribution. What's an appropriate level of "retroactive verification" of the account delivery in these cases?
  • Registration and Identity Proofing (4.2.2.3)
    • This language is in the section on "Registration" but it seems to be describing how to do Identity Proofing for Credential Issuance (the language in Credential Issuance says "Identity Vetting must meet same strength as in 4.2.2.3"). It's unclear to me what is required for verifying an "Address of Record" when the Registration Record is being created. Is this intended to be equivalent to a credit-check or some other 3rd party address verification process?
  • RA Authentication (4.2.2.4)
    • Assuming this refers to the credentials used to log into the systems where Subject records are created. E.g., PPS.
• LBNL
• UCOP