Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

Anthony Nadalin <> Thu, 02 February 2017 00:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16854129619; Wed, 1 Feb 2017 16:27:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ulvTR7qy2HwW; Wed, 1 Feb 2017 16:27:15 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9C101294F0; Wed, 1 Feb 2017 16:27:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QAR8gYyrYwmLMlmG6wP6MjbfegQ+DDQ7p3QCtMwxYYk=; b=Zqz0DzfhytwSTICykW9GCx73z5gr/3wPSztrOsrtO4E8YWXMX72q3sz1ZsFPCGGQvf4ktn4Prb+oVRw+KY79Zlkgw6B1+qK6moF7lo7HJ5H7QfVa+StawiVBbU5fvyqcsKspyFfH3DUjmRsQBaMkfpNy3AEGu3RGeIVyHE3CHXQ=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Thu, 2 Feb 2017 00:27:12 +0000
Received: from ([]) by ([]) with mapi id 15.01.0860.026; Thu, 2 Feb 2017 00:27:12 +0000
From: Anthony Nadalin <>
To: Stephen Farrell <>, Mike Jones <>, joel jaeggli <>, The IESG <>
Thread-Topic: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Date: Thu, 2 Feb 2017 00:27:12 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
x-ms-office365-filtering-correlation-id: 0477e73d-d6ea-4c15-fa00-08d44b023b5c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:SN2PR03MB2368;
x-microsoft-exchange-diagnostics: 1; SN2PR03MB2368; 7:sM4wlz+BC7v25eZmS0u2Et0NH3N3qwkB411bIyYQ6VtWO4a13YJs+XDGzv2a2zM35wyxr6oHLa/QT3LiPYWLEEbGchk94Mif2xOIl/mjlChMbA1Wx5TKZC2FAQeP34yNT05pVCzmiVOk2JVGRHVQKQRdnHC9oDBXiFiePAC86XjMNh/9EsHYruMrSHYS40OduONvq9PLXCP4Z18Vd/3hvmIu5k3E/9HmwfmjmPgNiHM1fmV4xWXooGrEqaMhAU2RpJl7YmtjGZbCVXxCw/lFulHgMrZhxR/5TbqLCzUh4WqTLFL12mEPVL3EhWRsT46zHMw1boFG/t74dSyVNQl+9CWfGmEv074lBmZj4uFc39G1HUhEOy7u+xPfPJe3oC6V/FKGNJ0DzzS8LCANaa+ZYJxiEzMa9pWTbaNd/0r+QBIs0KfdJlbB61TXgcZd3qqYqPLppY7Gj74fVtCzC0ietNsZO324GjwspQQr4K/anYKihugNYpVznvbD0HOyiyaQ/274YAlCHx5A+AYDpSiQUIL5W2WK1PitqHBdCN/Wg3Ek45tLIITsDjAZCGgE/5Rd
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(32856632585715)(120809045254105);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(20161123562025)(6072148); SRVR:SN2PR03MB2368; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2368;
x-forefront-prvs: 02065A9E77
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39410400002)(39860400002)(39850400002)(51444003)(51914003)(24454002)(13464003)(189002)(40224003)(377454003)(199003)(77096006)(3846002)(33656002)(86362001)(2421001)(25786008)(99286003)(106356001)(97736004)(106116001)(189998001)(105586002)(5001770100001)(8936002)(76176999)(81156014)(81166006)(10290500002)(38730400001)(50986999)(86612001)(8990500004)(5005710100001)(54356999)(8676002)(6506006)(122556002)(6436002)(10090500001)(2561002)(229853002)(68736007)(230783001)(66066001)(551544002)(966004)(93886004)(1511001)(3660700001)(4326007)(6116002)(9686003)(53936002)(101416001)(92566002)(5660300001)(102836003)(6306002)(3280700002)(3900700001)(55016002)(7736002)(305945005)(74316002)(54906002)(2900100001)(7696004)(2906002)(2950100002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR03MB2368;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 00:27:12.1266 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2368
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Feb 2017 00:27:18 -0000

We have interoped between FIDO authenticators vendors and Windows Hello

-----Original Message-----
From: Stephen Farrell [] 
Sent: Wednesday, February 1, 2017 4:24 PM
To: Mike Jones <>om>; Anthony Nadalin <>om>; joel jaeggli <>om>; The IESG <>
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

On 02/02/17 00:21, Mike Jones wrote:
> Thanks, Tony.  I can add that reference.
> Stephen, the sets of initial values were chosen from those used in
> practice by Microsoft and Google in real deployments.

Genuine questions: do you aim to have interop between those
deployments? What if I wanted to write code that'd interop
with msft or google?


> About "otp", there are existing use cases for indicating that an OTP
> was used.  I'm not aware of any of these use cases where the
> distinction between TOTP and HOTP is important.  Thus, having "otp"
> now makes sense, where having "hotp" and "totp" now doesn't.
> Stephen, this may seem like splitting hairs, but the registry
> instructions for "Specification Document(s)" are about having a
> reference for the document where the Authentication Method Reference
> Name (such as "otp") is defined.  In all cases for the initial
> values, this is the RFC-to-be, so the registry instructions are
> satisfied.  If someone were, for instance, to define the string
> "hotp", it would be incumbent on the person requesting its
> registration to provide a URL to the document where the string "hotp"
> is defined.  Also having a reference to RFC 4226 in that document
> would be a good thing, but that isn't what the registry instructions
> are about.
> All that said, I can look at also finding appropriate references for
> the remaining values that don't currently have them.  (Anyone got a
> good reference for password or PIN to suggest, for instance?)
> -- Mike
> -----Original Message----- From: Anthony Nadalin Sent: Wednesday,
> February 1, 2017 4:10 PM To: Stephen Farrell
> <>ie>; Mike Jones
> <>om>; joel jaeggli <>om>; The
> IESG <> Cc:;
>; Subject: RE:
> [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
> NIST asked for the addition of IRIS (as they are seeing more use of
> IRIS over retina due to the accuracy of iris)  as they have been
> doing significant testing on various iris devices and continue to do
> so, here is a report that NIST released
> -----Original Message----- From: Stephen Farrell
> [] Sent: Wednesday, February 1, 2017
> 2:26 PM To: Mike Jones <>om>; joel jaeggli
> <>om>; The IESG <> Cc:
> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
> Hi Mike,
> On 01/02/17 17:00, Mike Jones wrote:
>> Thanks for the discussion, Stephen.
>> To your point about "otp", the working group discussed this very 
>> point.  They explicitly decided not to introduce "hotp" and "totp" 
>> identifiers because no one had a use case in which the distinction 
>> mattered.
> Then I'm not following why adding "otp" to the registry now is a good
> plan.
> If there's a use-case now, then adding an entry with a good reference
> to the relevant spec seems right.
> If there's no use-case now, then not adding it to the registry seems
> right. (Mentioning it as a possible future entry would be fine.)
> I think the same logic would apply for all the values that this spec
> adds to the registry. Why is that wrong?
>> Others can certainly introduce those identifiers and register them
>> if they do have such a use case, once the registry has been
>> established.  But the working group wanted to be conservative about
>> the identifiers introduced to prime the registry, and this is such
>> a case.
>> What identifiers to use and register will always be a balancing
>> act. You want to be as specific as necessary to add practical and
>> usable value, but not so specific as to make things unnecessarily
>> brittle.
> Eh... don't we want interop? Isn't that the primary goal here?
>> While some might say there's a difference between serial number 
>> ranges of particular authentication devices, going there is
>> clearly in the weeds.  On the other hand, while there used to be an
>> "eye" identifier, Elaine Newton of NIST pointed out that there are 
>> significant differences between retina and iris matching, so "eye" 
>> was replaced with "retina" and "iris".  Common sense informed by 
>> actual data is the key here.
> That's another good example. There's no reference for "iris." If that
> is used in some protocol, then what format(s) are expected to be
> supported? Where do I find that spec? If we can answer that, then
> great, let's add the details. If not, then I'd suggest we omit "iris"
> and leave it 'till later to add an entry for that. And again,
> including text with "iris" as an example is just fine, all I'm asking
> is that we only add the registry entry if we can meet the same bar
> that we're asking the DE to impose on later additions.
> And the same for all the others...
> Cheers, S.
>> The point of the registry requiring a specification reference is
>> so people using the registry can tell where the identifier is
>> defined. For all the initial values, that requirement is satisfied,
>> since the reference will be to the new RFC.  I think that aligns
>> with the point that Joel was making.
>> Your thoughts?
>> -- Mike
>> -----Original Message----- From: OAuth 
>> [] On Behalf Of Stephen Farrell Sent: 
>> Wednesday, February 1, 2017 7:03 AM To: joel jaeggli 
>> <>om>; The IESG <> Cc: 
>> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss
>> on draft-ietf-oauth-amr-values-05: (with DISCUSS)
>> On 01/02/17 14:58, joel jaeggli wrote:
>>> On 1/31/17 8:26 AM, Stephen Farrell wrote:
>>>> Stephen Farrell has entered the following ballot position for 
>>>> draft-ietf-oauth-amr-values-05: Discuss
>>>> When responding, please keep the subject line intact and reply
>>>> to all email addresses included in the To and CC lines. (Feel
>>>> free to cut this introductory paragraph, however.)
>>>> Please refer to 
>>>> for 
>>>> more information about IESG DISCUSS and COMMENT positions.
>>>> The document, along with other ballot positions, can be found 
>>>> here: 
>>>> ---------------------------------------------------------------------
>>>> DISCUSS: 
>>>> ---------------------------------------------------------------------
>>>> This specification seems to me to break it's own rules. You
>>>> state that registrations should include a reference to a
>>>> specification to improve interop. And yet, for the strings
>>>> added here (e.g. otp) you don't do that (referring to section 2
>>>> will not improve interop) and there are different ways in which
>>>> many of the methods in section 2 can be done. So I think you
>>>> need to add a bunch more references.
>>> Not clear to me that the document creating the registry needs to
>>>  adhere to the rules for further allocations in order to
>>> prepoulate the registry. that is perhaps an appeal to future
>>> consistency.
>> Sure - I'm all for a smattering of inconsistency:-)
>> But I think the lack of specs in some of these cases could impact
>> on interop, e.g. in the otp case, they quote two RFCs and yet only
>> have one value. That seems a bit broken to me, so the discuss isn't
>> really about the formalism.
>> S.