Skip to Content.
Sympa Menu

mfa-interop - Re: [MFA-Interop] Use Cases Subgroup update

Subject: MFA Interop Working Group

List archive

Re: [MFA-Interop] Use Cases Subgroup update

Chronological Thread 
  • From: Nick Roy <>
  • To: "Farmer, Jacob" <>, "" <>
  • Subject: Re: [MFA-Interop] Use Cases Subgroup update
  • Date: Mon, 31 Aug 2015 20:39:40 +0000
  • Accept-language: en-US
  • Authentication-results: spf=none (sender IP is ) ;; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:23

Thanks Jacob - the geolocation question in use case #1, below, might be considered its own use-case, and not be specific to geolocation.  It also might supplant the "capricious reasons" use case:

-IdP force MFA when suspicious activity detected (missing cookie, multiple logins from different locations/IP addresses in a short period of time, user password entopy degraded for some reason, etc).


From: <> on behalf of "Farmer, Jacob"
Date: Monday, August 31, 2015 at 1:56 PM
To: ""
Subject: [MFA-Interop] Use Cases Subgroup update



I want to prove a quick update on the Use Cases subgroup.  We met last Tuesday and our full meeting notes are in the scribing document[1].  The primary deliverable was to create a collection of generalizable use cases, that can be used to guide the specification drafting process.  The scenarios that we have outlined are:


§  IdP forces MFA independent of inband SP signaling

·         IdP force MFA for specific SPs (presumably as the result of an out of band negotiation/requirement) Geographic location triggering this?

·         IdP force MFA for specific users

·         IdP force MFA for capricious reasons

·         (May not require signaling)

§  SP requested MFA (signaled via some interop profile)

·         SP require MFA for all users

·         SP require MFA for specific users

·         SP require MFA for specific transactions (e.g., escalation)

·         SP request MFA non exclusively, meaning it would only allow non-MFA users access to “non-sensitive” functionality SP request no MFA to constrain costs; consider IdP as a service where there is a cost per AuthN


In our next call, we will work on drafting more reader-friendly versions of these, but I think that this summary provides pretty good general understanding of the group’s thinking.


** The request that we have for the full group is this: are you aware of any concrete use cases that do not generalize down to one of the broad use cases?  If so, please feel free to share with the list, and we will adjust the generalized use cases as we go along.


I’ll share another update soon.







Jacob Farmer

Identity Management Systems

(812) 856-0186


Archive powered by MHonArc 2.6.16.

Top of Page