Assurance

[David Walker <>]

Mark,

Personally, I would say that 4.2.2 should be read the same way,
independent of whether it's read in sequence within the IAP, or if it's
referenced by another section.  I was one of the authors, but I wouldn't
want to speak for the others.  If this is an issue for institutions
trying to certify for Bronze, I'd suggest getting a read from the AAC.

Independent of that, though, I still think it's a good idea to know what
standards make sense for our community in 2015, whether they're in the
IAP or not.

David


On 01/12/2015 11:56 PM, Jones, Mark B wrote:
> I disagree.
> In the circumstance I highlighted:  "After expiration of the current
> Credential, if none of these methods is successful" 
> ALL of 4.2.2 applies to Bronze, if expired credentials are to be recoverable
> without the use of pre-registered methods, because of the clause in 4.2.4.3
> that states:  "the Subject must re-establish her or his identity with the
> IdPO per Section 4.2.2"
>
>> -----Original Message-----
>> From: 
>> 
>>  [
>> ]
>>  On Behalf Of David Walker
>> Sent: Monday, January 12, 2015 4:10 PM
>> To: 
>> 
>> Subject: Re: [Assurance] Bronze password reset
>>
>> Right, Mark; I overstated the issue.  4.2.2 places restrictions, but the
> only one
>> that applies to Bronze is the protection of PII.
>>
>> David
>>
>>
>> On 01/12/2015 01:01 PM, Jones, Mark B wrote:
>>> But Bronze does place specific restrictions on registration and
>>> identity proofing under a specific circumstance.
>>>
>>> In section 4.2.4.3 (which applies to Bronze explicitly) it states that
>>> "After expiration of the current Credential, 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."
>>> This clearly says that if you want to be able to renew or re-issue a
>>> credential after expiration and after all pre-registered recovery
>>> methods fail, the institution must comply with the registration and
>>> identity proofing as described in 4.2.2.  If an institution chooses
>>> not to comply with 4.2.2 then that is a choice to not renew or
>>> re-issue expired credentials unless they can be recovered using pre-
>> registered methods.
>>>> -----Original Message-----
>>>> From: 
>>>> 
>>>>  [
>>>> ]
>>>>  On Behalf Of David Walker
>>>> Sent: Monday, January 12, 2015 11:20 AM
>>>> To: 
>>>> 
>>>> Subject: Re: [Assurance] Bronze password reset
>>>>
>>>> +1
>>>>
>>>> It seems to me that a lot of this discussion reflects a desire to
>>>> codify
>>> common
>>>> community practice for identity proofing and account recovery that is
>>>> not part of the set of Bronze requirements, but does address higher
>>>> education business needs.  In that context, maybe we should focus on
>>>> what that practice should be, knowing that Bronze doesn't place any
>>>> specific restrictions on it.
>>>>
>>>> David
>>>>
>>>> On 01/12/2015 07:16 AM, Cantor, Scott wrote:
>>>>>> I'm wondering now if the sort-of defacto industry standard of
>>>>>> having a few pre-registered questions... your favorite color, name
>>>>>> of your first pet, favorite relatives name, city where you were
>>>>>> born...  is
>>> that
>>>> reasonable care?
>>>>> Probably. But I think the underlying point is that if you assume
>>>>> *no*
>>>> knowledge of the person, then if these typical measures fail as they
>>>> sometimes will, there's literally no way to safely recover the
>>>> account,
>>> even if
>>>> the person shows up in person with ID.
>>>>> But in actual practice, we *do* tend to assume some binding to a
>>>>> person,
>>>> even if it's weak or implicit, and we do fall back to that if remote
>>>> reset doesn't work. We don't just throw away non-guest accounts and
>>>> force somebody to get a new one if they're an affiliate.
>>>>> But none of that is codified in Bronze. I guess the real underlying
>>> question
>>>> is whether it's enough to just say "reasonable care". I suspect
>>>> that's in keeping with the idea of an unaudited assurance level.
>>>>> -- Scott
>>>>>