Skip to Content.
Sympa Menu

assurance - RE: [Assurance] silver, 2-factor, password requirements

Subject: Assurance

List archive

RE: [Assurance] silver, 2-factor, password requirements


Chronological Thread 
  • From: "Farmer, Jacob" <>
  • To: "" <>
  • Subject: RE: [Assurance] silver, 2-factor, password requirements
  • Date: Fri, 30 Nov 2012 21:13:41 +0000
  • Accept-language: en-US

They care about control of the credential and that it's the same person each
time, but they don't care what human being has the credential.

Jacob

-----Original Message-----
From:


[mailto:]
On Behalf Of Jones, Mark B
Sent: Friday, November 30, 2012 4:08 PM
To:

Subject: RE: [Assurance] silver, 2-factor, password requirements

I think it odd to care so much about strong authentication without caring
about the identity of the user. Why inconvenience the user with 2FA when you
don't even care who they are?

Since you do not agree with 800-63 are there any other standards to consider?

Are we going to follow a standard or not?
If we follow a standard, will that be 800-63 or something else?


-----Original Message-----
From:


[mailto:]
On Behalf Of Cantor, Scott
Sent: Friday, November 30, 2012 2:42 PM
To:

Subject: Re: [Assurance] silver, 2-factor, password requirements

On 11/30/12 3:18 PM, "Jones, Mark B"
<>
wrote:

>Ok... so if InCommon bears no risk why bother with a risk assessment?
>And how did the result come out to be 'moderate'?

There's legal risk and there's reputational risk.


I believe the assessment was done with respect to the question of whether to
strengthen the authentication process for the directly issued accounts, but
with an eye on how it would impact the plan for doing delegated access by
federated accounts, but Tom is better able to answer that.

>If there are two sets of accounts, which set have we been talking about?

I think the directly issued ones primarily.

>I agree that passwords are hopeless. But if you don't care who is
>authenticating then why care if they are using passwords?

Because I might care that the ability to authenticate as a given
*identifier* is suitably protected. The binding back to a physical person
might be irrelevant *to the RP*. It is very relevant to the organization that
provisioned the identifier, but the RP needs no explicit statement to that
effect that such a binding was done in any particular way.

To be honest, I think it's 800-63's desire to tie these concepts together
that is flawed. You may find it inutitive and obvious, but I find it very
clumsy and ineffective.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page