Child pages
  • Comments from Jim Basney - 2016-05-04

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

 
 
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...

 

...