Page History

...

How to transport the information that a second factor has been used for authentication?
- AuthnContextClassRef: https://refeds.org/profile/mfa (cf. https://wiki.refeds.org/display/CON/Consultation%3A+REFEDS+MFA+Profile)
- LoA Attribute: eduPersonAssurance, based on the recommendations of the REFEDS Assurance WG
How could initial identity vetting procedure be integrated in above flow?
- Where would vetted attributes come from, AA or IdP?
- How and by which component can be expressed which identity data was vetted?
How could registration of second factor (e.g. SMS) be integrated in above flow?
- Registration must be done independently, otherwise (in case an account has been hacked) an attacker might also be able to register or authenticate with a second factor
- Dedicated (central) IdP or equivalent web service
- Identity vetting?
- As for the POC, the second factor tokens will be registered (i.e. assigned to users) by the service administrator.
What are the security implications of this scenario?
- Are there ways to make the AA release LoA information for the wrong user?
- Is it a problem that the first and the second factor are checked by two different components?
- Are there ways to fool the AttributeChecker and get around it?
- What can/should be done to prevent that a user's IdP can assert the LoA value instead of the AA? (in case the IdP is not considered to be trustworthy)

References