Assurance

[Steven Carmody <>]

by any chance, is there a recording of this call available anywhere ?

a great topic -- several people here couldn't make it to the call, but 
are very interested.

On 3/26/15 8:35 AM, Emily Eisbruch wrote:
> Greetings,
>
> Please mark your calendar for the next Monthly Assurance Call,
> Wed., April 1, 2015 at noon ET.
>
> Connection Info:
> +1-734-615-7474
> +1-866-411-0013 (toll free US/Canada Only)
> Access code: 0129048#
>
> This call will feature a discussion on *Password Reset*, led by Eric
> Goodman, Identity and Access Management Architect, University of
> California Office of the President.
>
> We will start with a short introduction laying out the  issues, followed
> by open discussion.  During the discussion, we will consider questions
> such as:
>
>   * What is your policy and what is working / not working about it ?
>   * Is it worth codifying password reset procedures?
>   * Any recommendations to modify the language in the IAP for InCommon
>     to  consider?
>
>
> For reference, below Eric's January 2015 summary of an email thread on
> the password reset topic.
>
> Thank you and we look forward to your participation on the call.
> Emily
>
>
> =====================
> FOR REFERENCE:
> EMAIL THREAD SUMMARIZED BY ERIC GOODMAN AS OF JAN. 2015
>
> Hello and Happy New Year!
>
> At the end of last year I started a thread on the InCommon Participants
> mailing last year discussing account recovery/password reset and the
> Bronze IAP. It was pointed out (offline) that the InCommon Assurance
> mailing list is probably a more appropriate place for the discussion, so
> I’m posting a follow-up summary of that thread here instead of on the
> Participants list.
>
> My original message was asking about section 4.2.4.3 of the
> Bronze/Silver IAP. That section provides a list of approved password
> change methods, followed by the statement “if none of these methods is
> 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.” Because the section 4.2.2 applies only to Silver IAQ
> accounts, there’s ambiguity about what is acceptable for recovery of a
> Bronze IAQ account when the explicitly allowed mechanisms fail.
>
> In that thread, I asked for examples of processes campuses actually use
> to recovery Bronze IAQ accounts when the allowed methods in 4.2.4.3
> fail, and specifically how campuses that have certified/self-asserted
> compliance with Bronze determined/justified that such processes met the
> IAP requirements in this section.
>
> There was a good theoretical discussion of the requirements -- and I did
> even get one response (off-list) with an actual Bronze process example
> :). Reading between the lines of the theoretical discussion, I want to
> make some concrete statements and see if they capture what people are
> thinking and doing:
>
> How people interpret the IAP requirements:
>
> ·         For Silver: The list of allowed methods in 4.2.4.3 combined
> with the identity proofing processes defined in 4.2.2 comprise a
> complete list of allowed password change methods.
>
> ·         For Bronze: The list of allowed methods in 4.2.4.3 provide an
> incomplete list of allowed password change methods. Other methods would
> be considered to be acceptable/compatible if they meet the general
> Bronze IAP criteria outlined in section 3.1 that:
>
> o   “Assertions under this [Bronze] profile are likely to represent the
> same Subject each time a Subject identifier is provided” and
>
> o   “it is expected that IdPOs use reasonable care when [re-]issuing
> Credentials to confirm that a single individual applies for and receives
> a given Credential and its Authentication Secret.”
>
> How people apply this requirement (for recovery of Bronze accounts):
>
> a)      Users provide information that loosely (i.e., not Silver
> verified) binds their account to known, valid identity data. E.g., A
> user provides information that matches them to an employee or student
> record as part of creating/updating their account profile.
>
> b)      Account operators presume that (unverified), completely
> self-asserted information registered by a user in their profile
> accurately describes the real world owner of the account.
>
> If either are true, then we can use whatever mechanisms we see as
> meeting the “reasonable care” guideline to verify a real life person’s
> identity against the (a) referred to source system record or (b) the
> (unverified) profile data registered on the account, to perform account
> recovery operations.
>
> Implications:
>
> ·         Account operators presume that people provide accurate
> information as part of their account profiles, even if there’s no
> mechanism whatsoever to positively validate that presumption.
>
> o   E.g., if I registered an account using a fake name and other data, I
> wouldn’t be able to recover that account (if 4.2.4.3 methods fail), but
> some real person who happens to match the false information I provided
> could potentially take possession of the account. In this case, we fail
> the “it’s the same person each time” test, but arguably not in a way
> that violates the “reasonable care” metric.
>
> ·         For truly anonymous accounts (no name or other data that can
> be verified against externally), there is no recourse; if the 4.2.4.3
> methods fail the account is forever unrecoverable.
>
> ·         It’s arguable that the additional processes (beyond 4.2.4.3)
> account operators use for of recovery Bronze accounts should (must?) be
> registered as Alternative Means with InCommon.
>
> o   This contradicts the interpretation (above) that section 4.2.4.3 is
> an incomplete list of allowed methods for both Bronze.
>
> o   Alternative Methods processes are likely similar enough across
> campuses that relatively few would need to be created to cover most use
> cases .
>
> Is this a reasonable summary of how people look at account recovery for
> Bronze accounts?
>
> Thanks for your time, especially if you’ve read this far!
>
> --- Eric
>
>
>
>
> Emily Eisbruch, Technology Transfer Analyst
> Internet2
>
> office: +1-734-352-4996 | mobile +1-734-730-5749