Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values

John Bradley <> Wed, 20 January 2016 19:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B93E41A87C1 for <>; Wed, 20 Jan 2016 11:59:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h6LLLYF580qj for <>; Wed, 20 Jan 2016 11:59:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DEE861A02B1 for <>; Wed, 20 Jan 2016 11:59:10 -0800 (PST)
Received: by with SMTP id o11so15146871qge.2 for <>; Wed, 20 Jan 2016 11:59:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=OSuiJGTL6Vg9iEVx3x6zOXbhzDfXz8VgQwYGU95Yycs=; b=S3vsDdt3+wY3J+RWx/2OLXQuYdTxmiE2/3WMFtRmafRIwkRJJorAK6brfxnX+yifDW kg/peIglnx2hGbz17TuCs21F3A7r26gj+ovovC0rIQPQyIN9AbTfYAs9qDXFn9Ga4u6f /CY/vs9WQ30OD7UC8OfM5/izPp/Vpp1bJ+tIIdBzE4mhNrKZRFMaJzH73rszq6cihmP6 0+r1kZrR+AUdGIVR8wf3ocDf2TdLdGZgSqJjM3dh5GgwM8nI1fNs3WLwp6J2LAvXShVq TeXQgXeD4RLJ+qCLAjTZtuQ5I6E9OhDtdmv6Bf6TI1XBvWm6xl2pni/YLeNK0MdYwZNk 9azw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=OSuiJGTL6Vg9iEVx3x6zOXbhzDfXz8VgQwYGU95Yycs=; b=IucalXBoUMUt1ykuRZ8jNksCs8QXLxItT+JmW0rk8h5CvHssuE7IZ2vXaku2r+tiep ALzFb26F6VnAM0ycj/XA2rossswdFyuBzUtiwstEmsvLtjZOKWuHywjXIZFc889cRaqS qpjmHLtD8z7refZlT4INQyZcffmnHZd03QQDgT89HWqoGJvUGJY92KRoeDRXdO/4Nzyb KknIjHRGnJlKvXgSUR3ajCFqNam3Ra+PwI74TbPD6LfEhe37UdQTVrQTx/CWmVBj55jQ lbjK8fVv2pgdPVwjSPP3QabjvPNaN++fC+zgCXAXDAj59wwUslnmptY4Rvipc/VKE66g r+iQ==
X-Gm-Message-State: ALoCoQlmJ8+cRybtCUiGASOYU39Et2NYzIy+8fmu7L+vCoj5gWVBApfInSQDpp2ukjoqHpXu2i0IDVTHMC7kiKtweVnvd1kt9w==
X-Received: by with SMTP id b81mr48532555qge.44.1453319949858; Wed, 20 Jan 2016 11:59:09 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id c7sm14946721qkb.38.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 11:59:09 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_21DF6964-D166-40E7-B67A-56D12E957B48"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <>
In-Reply-To: <>
Date: Wed, 20 Jan 2016 16:59:05 -0300
Message-Id: <>
References: <> <> <>
To: William Denniss <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Jan 2016 19:59:13 -0000

I have always been on record as being against having this as a request parameter, and managed to keep it out of connect.
So will be looking to do the same with this.

In a response as a list of that methods were used it is mostly harmless.  People think they need it until they discover that it is not really useful in most circumstances.

The methods listed are really not useful,  but might be OK as general categories of response.

Fido U2F and UAF fall into what I would call Phishing resistant credentials,  is that something a RP should care about or is that reflected in the LoA.

In the MODRNA profile of OpenID Connect I added some other ones to indicate if the key is hardware or software etc.

This is probably a OK place to start from so I am OK with adopting it, but will push for change:)

John B.

> On Jan 20, 2016, at 3:38 AM, William Denniss <> wrote:
> On Wed, Jan 20, 2016 at 12:37 PM, Manger, James < <>> wrote:
> Accepting draft-jones-oauth-amr-values-03 is almost okay as a starting point for work.
> +1 for adoption.
> I would like to see significant changes though:
> * The "amr_values" parameter should be dropped; it just encourages brittle designs as section 4 "relationship to acr" and section 6 "security considerations" already warn about. There is no need to enable that brittleness. If someone really wants this functionality they could put an amr value in the "acr_values" field as a hack.
> I agree that it seems to encourage brittle designs. Why would the OP want to use "otp" when it has U2F on file for the same user, for example? But come to think of it, is any use of "amr" non-brittle?  I guess the broader ones like "user", "rba", "mca" and "mfa" are a little more future-proof.
> I'm very keen to hear some concrete use-cases for this parameter.
> * The model for amr_values is wrong as well. For example, "amr":["pwd","otp"] could be a common response that you want, but you cannot ask for that with amr_values since amr_values="pwd otp" actually means just "pwd", or just "otp" is okay (and just "pwd" is your preference).
> * Registering values on a "Specification Required" basis is over-the-top. This doc registers 8 amr values with just a few words as each value's "specification" (eg "eye": retina scan biometric). Each of the other 7 amr values are "specified" in a few lines with a reference (or two). A "First Come First Served" basis is probably sufficient, with the "specification" just the description in the registry (that can include references).
> I agree, "Specification Required" does seem like a high bar.
> --
> James Manger
> -----Original Message-----
> From: OAuth [ <>] On Behalf Of Hannes Tschofenig
> Sent: Tuesday, 19 January 2016 10:48 PM
> To: <>
> Subject: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values
> Hi all,
> this is the call for adoption of Authentication Method Reference Values, see
> <>
> Please let us know by Feb 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group.
> Note: The feedback during the Yokohama meeting was inconclusive, namely
> 9 for / zero against / 6 persons need more information.
> You feedback will therefore be important to find out whether we should do this work in the OAuth working group.
> Ciao
> Hannes & Derek
> _______________________________________________
> OAuth mailing list
> <>
> <>
> _______________________________________________
> OAuth mailing list
> <>
> <>