...
| Subject: | RE: [Assurance] comments on draft MFA Interop WG documents |
|---|---|
| Date: | Wed, 4 May 2016 13:48:10 +0000 |
| From: | Cantor, Scott <cantor.2@osu.edu> |
| Reply-To: | assurance@incommon.org |
| To: | assurance@incommon.org <assurance@incommon.org> |
>
I
hope
we
don't
need
to
require
an
addendum
for
MFA...
>
>
I
think
the
intent
was
for
self-assertion.
I
won't
speak
for
the
WG,
but
while
working
on
the
material,
I
had
been
operating
under
the
assumption
this
was
not
an
assurance
category
at
all
but
a
self-asserted
AuthnContextClassRef
(in
SAML
terms),
just
like
many
others
defined
in
SAML
already.
Thus
the
idea
of
a
self-asserted
category
to
go
with
a
self-asserted
AuthnContext
seemed
redundant
(but
that
may
prove
not
to
be
the
case
for
other
reasons).
I
didn't
actually
notice
the
naming
convention
in
the
URI
included
the
word
assurance,
and
tend
to
think
that
may
be
confusing
as
a
result
and
worth
reconsidering
before
this
finalizes.
Sometimes
the
obvious
doesn't
hit
you
when
you're
staring
at
it
closely.
--
Scott
| Subject: | RE: [Assurance] comments on draft MFA Interop WG documents |
|---|---|
| Date: | Wed, 4 May 2016 14:00:43 +0000 |
| From: | Jokl, James A. (Jim) (jaj) <jaj@virginia.edu> |
| Reply-To: | assurance@incommon.org |
| To: | assurance@incommon.org <assurance@incommon.org> |
+1
I
made
it
to
many
of
the
calls
and
always
had
the
self-asserted
picture
in
my
mind
as
the
basic
perspective
--
that
this
was
about
passwords
no
longer
being
adequate
and
what
is
the
new
baseline
authentication.
I
still
think
of
this
stuff
as
"Standard
Assurance"
-
good
for
whatever
applications
you
used
to
just
use
and
ID/Password
for
-
but
I
get
Scott's
point
too
about
the
name.
Note
that
this
work
took
a
nice
low
bar
on
the
technical
side
-
almost
anything
that
you
can
call
a
second
factor
is
acceptable
--
and
there
is
no
discussion
about
identity
proofing.
All
good
for
self-asserted,
perhaps
less
so
if
people
were
thinking
differently.
Jim
| Subject: | RE: [Assurance] comments on draft MFA Interop WG documents |
|---|---|
| Date: | Wed, 4 May 2016 14:38:18 +0000 |
| From: | Paul Caskey <pcaskey@internet2.edu> |
| Reply-To: | assurance@incommon.org |
| To: | assurance@incommon.org <assurance@incommon.org> |
+1
to
all
of
that
and
yes,
IMHO,
we
should
not
use
the
word
'assurance'
to
refer
to
this
context.
| Subject: | Re: [Assurance] comments on draft MFA Interop WG documents |
|---|---|
| Date: | Wed, 4 May 2016 09:24:57 -0700 |
| From: | David Walker <dwalker@internet2.edu> |
| Reply-To: | assurance@incommon.org |
| To: | assurance@incommon.org |
I'll take responsibility for putting the work "assurance" in the URI. I did it without much thought, and it certainly can be changed. In fact, the plan is to replace it with a URI in the REFEDS name space, anyway. I agree with everyone that the MFA authentication context should be self-asserted. I think the real question is whether IdPs that support the MFA profile should also be given a (presumably self asserted) entity category in metadata. The current draft does not recommend an entity category, as the group didn't see use cases where it would help. We have since, however, heard of SPs that would like to tailor their discovery interfaces to exclude non-MFA-supporting IdPs, and there are situations where an entity category can save an SP from issuing a second authentication request when it prefers MFA, but will accept anything else. Do others have use cases for an IdP entity category that it supports the MFA profile? It's certainly not too late to define one. David
| Subject: | RE: [Assurance] comments on draft MFA Interop WG documents |
|---|---|
| Date: | Wed, 4 May 2016 16:35:02 +0000 |
| From: | Paul Caskey <pcaskey@internet2.edu> |
| Reply-To: | assurance@incommon.org |
| To: | assurance@incommon.org <assurance@incommon.org> |
It was the discovery use case I had in mind...
...