[keycloak-dev] acr and acr_values

[Martin Hardselius]

Seems like there's a draft on VoT that applies to OpenID Connect:
https://tools.ietf.org/html/draft-richer-vectors-of-trust-04#section-4.2

On Thu, 16 Feb 2017 at 15:25 Bill Burke <bburke at redhat.com> wrote:

> We'll just be attacking authentication vector of trust.
>
>
> On 2/16/17 4:31 AM, Schuster Sebastian (INST/ESY1) wrote:
> > Hi all,
> >
> > there is an upcoming standard on Levels of Assurance at NIST
> https://pages.nist.gov/800-63-3/.
> > Justin Richer blogged about it here
> https://medium.com/@justinsecurity/vectors-of-trust-ed52a57fe025#.c9eo8ihmx
> > Maybe that's interesting in this context.
> >
> > Best regards,
> > Sebastian
> >
> > -----Ursprüngliche Nachricht-----
> > Von: keycloak-dev-bounces at lists.jboss.org [mailto:
> keycloak-dev-bounces at lists.jboss.org] Im Auftrag von Stian Thorgersen
> > Gesendet: Donnerstag, 16. Februar 2017 09:21
> > An: Martin Hardselius <martin.hardselius at gmail.com>
> > Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> > Betreff: Re: [keycloak-dev] acr and acr_values
> >
> > Can you elaborate on your use-case?
> >
> > We have some plans to introduce a step-up-authentication mechanism. The
> main idea is to have the concept of authentication levels. In the
> authentication flows there would be additional metadata that would set the
> authentication level. This means the authentication level can be set
> independently to authenticators and authenticators doesn't even have to be
> aware of it.
> >
> > In summary a login flow would look something like:
> >
> > * Username/password form
> > * Set authentication level = 1
> > * OTP form
> > * Set authentication level = 2
> >
> > Behind the covers the authentication processor would know at which point
> in the flow it's possible to exit the flow depending on the level requested.
> > The level requested would be base on:
> >
> > * Realm default
> > * Client default
> > * Client requested
> >
> > It would also support the client being able to initially request for
> level
> > 1 then later ask for level 2. The authentication processor would it that
> case be able to skip the parts of the flow that was previously executed.
> >
> > We also had an idea about allowing alternative flows depending on what
> level you are going from and to. This could be relevant if authenticators
> allow collecting more than one thing on a single form. For example there
> could be alternative authenticators for username-only, username+password,
> > username+password+otp. This would be done by having conditions on which
> > flow to select.
> >
> >
> > On 15 February 2017 at 14:46, Martin Hardselius <
> martin.hardselius at gmail.com
> >> wrote:
> >> We're in the process of adding support for different levels of
> >> assurance in our custom installation, which means that proper support
> >> for acr and acr_values is becoming more of a priority. What's the
> >> status on this? Can we assist with a PR?
> >>
> >> https://issues.jboss.org/browse/KEYCLOAK-3314
> >>
> >> This might fit better into keycloak-user, but if you already have
> >> plans for acr-stuff, or planned refactorings that would affect how
> >> this is implemented, I'd be happy for some advice on how to proceed
> >> with a temporary solution.
> >>
> >> Regards,
> >> Martin
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>