Assurance

[David Langenberg <>]

As for how 4.2.4.5 pertains to 4.2.4.3.2, what were you imagining the
implementation would require?  Would allowing the user to call the
helpdesk & ask "Is this legit?" be sufficient or are we imagining a
more technical implementation where if transmitted electronically the
message must be signed somehow?

Dave

On Fri, Nov 16, 2012 at 10:25 AM, Ann West 
<>
 wrote:
> Hello All,
>
> As I mentioned last week in my note regarding the meaning of the term 
> "industry standard," we're discussing several possible updates to the 
> Profile and Framework documents and would like to get your thoughts 
> regarding your ability to support these requirements and the ease to which 
> you can do so.
>
> As you know, we currently don't include Bronze in the Credential Issuance 
> section of the IAP. FICAM's request is that we align Bronze more tightly 
> with their program in this area, and we have responded by drafting an 
> updated 4.2.4 Credential Issuance and Management section.
>
> I've copied the entire section below, so you can see the scope of the 
> possible changes: 4.2.4.1 and 4.2.4.2 remain unchanged except they now 
> apply to Bronze in addition to Silver; 4.2.4.3 now also applies to Bronze 
> and, while we were editing the spec, the language has been clarified; the 
> retention period in 4.2.4.4. has increased, an issue I vetted with the CIC 
> and several other schools late summer; and 4.2.4.5 is new.
>
> We invite you to send your thoughts to this list over the next week.
>
> Best,
> Ann
>
> -----
> DRAFT
>
> 4.2.4        CREDENTIAL ISSUANCE AND MANAGEMENT
> The authentication Credential must be bound to the physical Subject and to 
> the IdMS record pertaining to that Subject.
>
> 4.2.4.1         (S) (B)  CREDENTIAL ISSUANCE
> To ensure that the same Subject acts throughout the registration and 
> Credential issuance process, the Subject shall identify himself or herself 
> in any new transaction (beyond the first transaction or encounter) with 
> information known only to the Subject, for example a temporary Secret which 
> was established during a prior transaction or encounter, or sent to the 
> Subject’s Address of Record.  When identifying himself or herself in 
> person, the Subject shall do so either by using a Secret as described 
> above, or through the use of an equivalent process that was established 
> during a prior encounter.
>
> 4.2.4.2        (S) (B)  CREDENTIAL REVOCATION OR EXPIRATION
> 1. The IdPO shall revoke Credentials within 72 hours after being notified 
> that a Credential is no longer valid or is compromised.
> 2. If the IdPO issues Credentials that expire automatically within 72 hours 
> or less then the IdPO is not required to provide an explicit mechanism to 
> revoke the Credentials.
>
> 4.2.4.3        (S) (B)  CREDENTIAL RENEWAL OR RE-ISSUANCE
> A Subject must be authenticated for purpose of Credential renewal or 
> re-issuance by any of the following methods:
> 1.        By use of a non-expired and valid Credential.
> 2.        By use of a single-use secret delivered to the Subject from the 
> IdPO by means of a pre-registered out of band delivery mechanism.
> 3.        The Subject may supply correct answers to pre-registered 
> personalized questions designed to be difficult for any other person to 
> know.
> After expiration of the current Credential, if none of these methods are 
> successful then the Subject must re-establish her or his identity with the 
> IdPO per Section 4.2.2 before the Credential may be renewed or re-issued.
> Authentication Secrets shall not be recovered; new Authentication Secrets 
> shall be issued.
>
> 4.2.4.4         (S)  CREDENTIAL ISSUANCE RECORDS RETENTION
> The IdPO shall maintain a record of the unique identifier and time of 
> issuance or revocation of each Credential issued or revoked for a minimum 
> of 7.5 years beyond the expiration of the Credential.
>
> 4.2.4.5        (S) (B) RESIST TOKEN ISSUANCE TAMPERING THREAT
> The process or processes used by the IdPO in 4.2.4.1, 4.2.4.2, and 4.2.4.3 
> must enable the Subject to verify that the IdPO is the source of any token 
> or Credential data they receive.



-- 
David Langenberg
Identity & Access Management
The University of Chicago