This document proposes a new model for Level of Assurance (LOA) that separates it into two parts: Level of Strength (LoS) of authentication and Level of Confidence (LoC) of attributes. LoS would measure the strength of the authentication process using levels like single-factor, two-factor, or two-factor with hardware token. LoC would measure the degree to which a relying party can depend on attributes based on the identity proofing process using levels like self-asserted, remotely verified, or in-person verified. This new model aims to avoid problems with the current LOA structure and emphasize meaningful distinctions between levels.

1. LOA
Alterna+ves:
A
Modest
Proposal
Jim
Fenton
IIW
XX
April
2015

2. Background
• LOA
is
defined
in
OMB
Memo
M-­‐04-­‐04,
“E-­‐
Authen+ca+on
Guidance
for
Federal
Agencies”
• Technical
means
to
sa+sfy
are
defined
in
NIST
SP
800-­‐63-­‐*
• Federal
authen+ca+on
requirements
are
changing
due
to
Execu+ve
Order
13681

3. EO
13681
“…all
agencies
making
personal
data
accessible
to
ci+zens
through
digital
applica+ons
require
the
use
of
mul+ple
factors
of
authen+ca+on
and
an
effec+ve
iden+ty
proofing
process,
as
appropriate.”
-­‐-­‐
Execu+ve
Order
13681
October
17,
2014
Ø Current
LOA
1
and
2
are
going
to
be
a
lot
less
useful

4. Three
Alterna+ves
for
OMB
• (1)
Keep
current
LOA
structure,
change
impact
– Increase
impact
of
personal
data
disclosure
– Drives
more
things
to
LOA
3
• (2)
Keep
LOA
structure,
change
800-­‐63
– Likely
to
confuse
agencies
and
industry
• (2)
Change
the
LOA
structure
somehow
– Let’s
discuss
this
more

5. Some
principles
• Avoid
current
LOA
problems
– LOA
2
both
proofed
and
pseudonymous
– No
strong
pseudonymous
authen+ca+on
– Lower
LOA
geeng
less
useful
• Keep
it
simple
– Emphasize
meaningful
dis+nc+ons
between
levels
– Minimize
dimensionality
(of
vector)

6. Meaningful
dis+nc+ons?
• As
mul+-­‐factor
authen+ca+on
becomes
more
widely
used,
dis+nc+ons
in
single-­‐factor
become
less
important
Authen'ca'on
LOA
Proofing
Single
factor
1
None
Single
factor
2
pseudonymous
None
Single
factor
2
Remote
Mul+-­‐factor
3
Remote
Mul+-­‐factor
w/
hardware
token
4
In-­‐person
only
{
Similar
(though
not
iden+cal)
requirements
}
Similar
(though
not
iden+cal)
requirements

7. A
New
Model
• Separate
Level
of
Assurance
into
two
parts:
– Level
of
Strength
(of
authen+ca+on)
– Level
of
Confidence
(of
akributes)
• Emphasis
on
meaningful
dis+nc+ons
– Significant
differences
in
usability,
availability
– Require
good
prac+ces
internally
(e.g.,
use
of
crypto
rather
than
shared
secrets)
• Emphasis
on
expressing
the
relying
party’s
requirements
to
the
user
and
authen+ca+on
and
akribute
providers

8. Level
of
Strength
(LoS)
• Measures
the
strength
of
the
authen+ca+on
process
• Candidate
levels:
• Detailed
requirements
per
level
to
be
defined
in
SP
800-­‐63-­‐2
successor
Level
Descrip'on
1
Single-­‐factor
authen+ca+on
(cf.
LOA
2)
2
Two-­‐factor
authen+ca+on
(cf.
LOA
3)
3
Two-­‐factor
authen+ca+on
with
hardware
token
(cf.
LOA
4)

9. Level
of
Confidence
(LoC)
• Measure
of
the
degree
to
which
the
Relying
Party
can
depend
on
akributes,
par+cularly
iden+fying
akributes
• Incorporates
the
iden+ty
proofing
process
and
the
binding
to
the
creden+al
• Again,
detailed
requirements
TBD.
Level
Descrip'on
1
Self-­‐asserted
akribute
(cf.
LOA
1)
2
Remotely
iden+ty
proofed
(cf.
LOA
3)
3
In-­‐person
iden+ty
proofed
(cf.
LOA
4)

10. Mapping
LOA
to
LOS/LOC
LOA
Level
of
Strength
Level
of
Confidence
1
1
(see
note)
1
2
1
1
(pseudonynous)
or
2
3
2
2
4
3
3
Note:
Some
LOA
1
authen+ca+on
methodologies
may
not
be
acceptable
at
LOS
1.

11. Mapping
LOS/LOC
to
LOA
LOC
1
LOC
2
LOC
3
LOS
1
1,
2P
2
Note
2
LOS
2
Note
1
3
Note
2
LOS
3
Note
1
4
Notes:
1.
Strong
pseudonymous
or
anonymous
authen+ca+on
2.
Lower
LOS
may
limit
effec+ve
LOC

12. Not
included
• Characteris+cs
of
authen+ca+on
and
akribute
provider
– Accredita+on
of
the
authen+ca+on
or
akribute
provider
• May
only
permit
certain
levels
of
asser+on
– Trust
by
relying
party
of
accredi+ng
agency
• Addi+onal
detail
(such
as
loca+on)
for
risk-­‐based
authen+ca+on
decisions
– Are
these
really
akributes?
• Risk
characteris+cs
at
each
level
– To
be
defined
based
on
detailed
technical
requirements
at
each
level
• Asser+on
metadata
– Expira+on,
usage
restric+ons,
etc.