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

Mike Jones <Michael.Jones@microsoft.com> Thu, 02 February 2017 00:35 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA380129577; Wed, 1 Feb 2017 16:35:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.157
X-Spam-Level:
X-Spam-Status: No, score=-3.157 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_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2_OtpSWNyc2; Wed, 1 Feb 2017 16:35:37 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0108.outbound.protection.outlook.com [104.47.36.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08731294F0; Wed, 1 Feb 2017 16:35:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KVPMZAU/jJoLmTJ+5qR93vkRAutFNl0J4MBT/5IB1f4=; b=OTaHem5xOYqzU0idXk+7ZBSXVcyDu4gIAOAQ5B9vHTnZdaNUNdgqNAM1tDjPIw6r3rXS3AEKzUIGr8eIwbLw2htbhgyxJTi+9+pY/r5ofgGk3D2szdp3EG25lTGffH5lEGOAHlPc81GEmQkSgBCH4B3287kzpspNXoXrkRfzvYI=
Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by CY1PR0301MB2027.namprd03.prod.outlook.com (10.164.2.21) 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:35:34 +0000
Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0874.021; Thu, 2 Feb 2017 00:35:33 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Anthony Nadalin <tonynad@microsoft.com>, joel jaeggli <joelja@bogus.com>, The IESG <iesg@ietf.org>
Thread-Topic: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Thread-Index: AQHSe97H5hXZpqeBE0CT6lHMY4yQFKFUP6sAgAABIQCAAB5D0IAAXXiAgAAdOACAAABqIIAAA2uAgAAA3wCAAAAzAIAAAO4AgAAAVZA=
Date: Thu, 2 Feb 2017 00:35:33 +0000
Message-ID: <BN3PR03MB23555D125FBA8EC4ECCA5A9CF54C0@BN3PR03MB2355.namprd03.prod.outlook.com>
References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> <c0e62125-14e6-2390-87e3-72a2422f732f@bogus.com> <d9d0f5ae-6dcd-98cc-6113-96e937332b60@cs.tcd.ie> <BN3PR03MB23559422F9C2474DB04094FEF54D0@BN3PR03MB2355.namprd03.prod.outlook.com> <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> <SN1PR0301MB2029EF1377E24CD330C5C929A64C0@SN1PR0301MB2029.namprd03.prod.outlook.com> <BN3PR03MB2355204C821E8E1807143F95F54C0@BN3PR03MB2355.namprd03.prod.outlook.com> <268ffcf0-2f90-049e-1a3c-03b39d62c338@cs.tcd.ie> <SN1PR0301MB2029F5A8F803768C1D764543A64C0@SN1PR0301MB2029.namprd03.prod.outlook.com> <BN3PR03MB2355831A747ED03DC3B6608CF54C0@BN3PR03MB2355.namprd03.prod.outlook.com> <da5d0f13-58c8-734a-4edf-5988a8aa7aed@cs.tcd.ie>
In-Reply-To: <da5d0f13-58c8-734a-4edf-5988a8aa7aed@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-originating-ip: [2001:4898:80e8:c::388]
x-ms-office365-filtering-correlation-id: b6d264ec-960a-41fe-ca75-08d44b036623
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB2027;
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB2027; 7:G4XjEiRby3EmiiZeij17gkDxFlQ2OzVQwagJS/5ydtQvFKqxbJw6cyU9exroXdbpu+eSTSncmrytUq22mWOBdVpbtP+/e8p8KoUZ4VHTFlTBdwPjWgIyd+77A5fI/Z86OkjNz0NYIQ9j62IeAXU147vS92fa0JozFIwvsI2U3hABmDz+k+b4CxMgolG+R3fAL+o906ppN+jPJa58IUovm8IbphLffhoURYOTiMeMO3+HPtx8m4L/01Kk2nnQlltLYTTglkAouR0fD3Q+Lw6R6Fo9lfAlilUSBh8gLOJ7zcCFhOOPAO/j0/bwrxSzgRO8E+etfAJhgUwwS3sdqaerQFRs9IN7f6ONUlaLXfx8I/fE5uXIvaTSgruG9ggu++l/tRgKOZ5F6RufJRl053X2myZuLCIq49KjT4vZVBbW3OnVX3ZDeLZC/0Om8U8opGd3oSc4k3TmdOgrznAGphgoZjdeMWnYJJImaV62sGQStZvJOYM3zRPCRYcecMSCkBT0SrsbJofYaS0IbE3GsvFchosafDfjmtCFZ6go/M/XRp3PxBB5ggu+cNp9TNlz7pve
x-microsoft-antispam-prvs: <CY1PR0301MB202781E2F7067B3685713B8AF54C0@CY1PR0301MB2027.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(32856632585715)(120809045254105)(21532816269658);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:CY1PR0301MB2027; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB2027;
x-forefront-prvs: 02065A9E77
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39450400003)(39410400002)(39840400002)(199003)(13464003)(24454002)(40224003)(377454003)(189002)(51914003)(1511001)(86612001)(6436002)(106356001)(305945005)(77096006)(10090500001)(229853002)(122556002)(105586002)(38730400001)(6506006)(53936002)(106116001)(551544002)(99286003)(7736002)(54906002)(966004)(25786008)(55016002)(189998001)(93886004)(50986999)(54356999)(101416001)(76176999)(230783001)(9686003)(6306002)(8676002)(86362001)(97736004)(81156014)(92566002)(5660300001)(81166006)(5001770100001)(2950100002)(2561002)(33656002)(2421001)(7696004)(4326007)(3900700001)(3280700002)(2906002)(8936002)(68736007)(3660700001)(74316002)(2900100001)(6116002)(102836003)(8990500004)(5005710100001)(10290500002)(522254002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB2027; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com 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-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 00:35:33.3906 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB2027
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/LOkdM2ECC5Iw2Cndly1XfnEOTX0>
Cc: "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>, "draft-ietf-oauth-amr-values@ietf.org" <draft-ietf-oauth-amr-values@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2017 00:35:40 -0000

You can call me lazy if you want.  Some of them are so well known, such as "password" or "PIN" it didn't seem worthwhile to try to track down a reference.  But I'm willing to work with others to find decent references for the rest of them, if you believe that would improve the quality of the specification.

				Best wishes,
				-- Mike

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
Sent: Wednesday, February 1, 2017 4:31 PM
To: Mike Jones <Michael.Jones@microsoft.com>;; Anthony Nadalin <tonynad@microsoft.com>;; joel jaeggli <joelja@bogus.com>;; The IESG <iesg@ietf.org>;
Cc: oauth-chairs@ietf.org; draft-ietf-oauth-amr-values@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)



On 02/02/17 00:28, Mike Jones wrote:
> The other case of known interop testing of "amr" values is for MODRNA
> (OpenID Connect Mobile Profile) implementations.  There's a reference
> to its use of "amr" values in the spec.

Yeah, iirc, that one seemed ok (assuming the reference tells
me what code to write which I assume it does).

I'm still not seeing why some do have sufficient references
and others do not.

Is there some difficulty with finding references or something?

S

> 
> -----Original Message----- From: Anthony Nadalin Sent: Wednesday,
> February 1, 2017 4:27 PM To: Stephen Farrell
> <stephen.farrell@cs.tcd.ie>;; Mike Jones
> <Michael.Jones@microsoft.com>;; joel jaeggli <joelja@bogus.com>;; The
> IESG <iesg@ietf.org>; Cc: oauth-chairs@ietf.org;
> draft-ietf-oauth-amr-values@ietf.org; oauth@ietf.org Subject: RE:
> [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
> 
> We have interoped between FIDO authenticators vendors and Windows
> Hello
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, February 1, 2017
> 4:24 PM To: Mike Jones <Michael.Jones@microsoft.com>;; Anthony Nadalin
> <tonynad@microsoft.com>;; joel jaeggli <joelja@bogus.com>;; The IESG
> <iesg@ietf.org>; Cc: oauth-chairs@ietf.org;
> draft-ietf-oauth-amr-values@ietf.org; oauth@ietf.org 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?
> 
> S.
> 
>> 
>> 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 
>> <stephen.farrell@cs.tcd.ie>;; Mike Jones 
>> <Michael.Jones@microsoft.com>;; joel jaeggli <joelja@bogus.com>;;
>> The IESG <iesg@ietf.org>; Cc: oauth-chairs@ietf.org; 
>> draft-ietf-oauth-amr-values@ietf.org; oauth@ietf.org 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 
>> http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-report-evaluates-needle-haystack-search-capability.html
>>
>>
>>
>> 
-----Original Message----- From: Stephen Farrell
>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, February 1,
>> 2017 2:26 PM To: Mike Jones <Michael.Jones@microsoft.com>;; joel
>> jaeggli <joelja@bogus.com>;; The IESG <iesg@ietf.org>; Cc: 
>> oauth-chairs@ietf.org; draft-ietf-oauth-amr-values@ietf.org; 
>> oauth@ietf.org 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 
>>> [mailto:oauth-bounces@ietf.org] On Behalf Of Stephen Farrell
>>> Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli 
>>> <joelja@bogus.com>;; The IESG <iesg@ietf.org>; Cc: 
>>> oauth-chairs@ietf.org; draft-ietf-oauth-amr-values@ietf.org; 
>>> oauth@ietf.org 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 
>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for
>>>>>  more information about IESG DISCUSS and COMMENT positions.
>>>>> 
>>>>> 
>>>>> The document, along with other ballot positions, can be found
>>>>>  here: 
>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 
---------------------------------------------------------------------
>>>>> 
>>>>> 
>> 
>>>>> 
> -
>>>>> 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.
>>> 
>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>