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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 07 March 2017 18:10 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 211F21294FB; Tue, 7 Mar 2017 10:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
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 DFYRjXEjHT1N; Tue, 7 Mar 2017 10:10:45 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE401294EE; Tue, 7 Mar 2017 10:10:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7BFBFBE38; Tue, 7 Mar 2017 18:10:43 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tNlBT6Ohq7Z; Tue, 7 Mar 2017 18:10:40 +0000 (GMT)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 68794BE55; Tue, 7 Mar 2017 18:10:39 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1488910240; bh=g7PdIEmwsnBBEJVDs2iZTwN3XEGS92NSkP2DzmwdJ4M=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=TbRCQDKw7qnoZOyuou8707+IUBqAcFdnau8wde/EEzZ94GET8dhkFBut8FIiETj59 JA+TBYXLHl6i39sd2G1n8o8HwIGQ4QbXWzIwJFX46bv+BmCDOsbhJdJr/W63IpBeLY e8h0z/dGTdde0IGbqRHP/VhlKlsa/flAw4P+MFnA=
To: Mike Jones <Michael.Jones@microsoft.com>, Anthony Nadalin <tonynad@microsoft.com>, joel jaeggli <joelja@bogus.com>, The IESG <iesg@ietf.org>
References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.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> <BN3PR03MB23555D125FBA8EC4ECCA5A9CF54C0@BN3PR03MB2355.namprd03.prod.outlook.com> <2972e6a5-2bdb-3047-2086-271730dfc3ef@cs.tcd.ie> <CY4PR21MB05045C7B1A47A7AC9CFA362EF5290@CY4PR21MB0504.namprd21.prod.outlook.com> <CY4PR21MB0504360DE5B915C42B17C02DF52C0@CY4PR21MB0504.namprd21.prod.outlook.com> <a6f3617e-bdd9-114b-4025-b957efa12bc2@cs.tcd.ie> <CY4PR21MB050481D8CF7B8551D21F38A8F52C0@CY4PR21MB0504.namprd21.prod.outlook.com> <a78de3c1-7d73-8147-8540-0bc23fca366d@cs.tcd.ie> <CY4PR21MB0504A12F9CE5E8A66C0B790AF52F0@CY4PR21MB0504.namprd21.prod.outlook.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <da9a6295-8d8a-0d4d-e095-702bf679729d@cs.tcd.ie>
Date: Tue, 7 Mar 2017 18:10:38 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CY4PR21MB0504A12F9CE5E8A66C0B790AF52F0@CY4PR21MB0504.namprd21.prod.outlook.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OMSItXHpSXaumCNRTlLIVDap7hMpirI6l"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Z2FBaYkZD1INBwu0Yk-M5FfZLyE>
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: Tue, 07 Mar 2017 18:10:49 -0000


On 07/03/17 17:17, Mike Jones wrote:
> You're right, Stephen.  Re-reading the spec, it doesn't say that, and
> it should.  Sometimes it takes someone giving a spec a fresh read to
> uncover things that the authors understood and intended but failed to
> be captured in the text.  This is such a case - so thanks.
> 
> I'll add this information, which is necessary to understand the
> intent, and then republish.

Ah good, that explains the disconnect.

Cheers,
S.

> 
> -- Mike
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:stephen.farrell@cs.tcd.ie] Sent: Monday, March 6, 2017 2:39
> 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)
> 
> 
> Hi Mike,
> 
> On 06/03/17 22:34, Mike Jones wrote:
>> Thanks for the reply, Stephen.  I'll try to find better 
>> interop-producing references where possible.
>> 
>> 
>> In some cases, however, the values are intentionally intended to 
>> provide an identifier for a family of closely-related methods, such
>> as "otp", which covers both time-based and HMAC-based OTPs.
> 
> Hmm. I don't recall text saying that in the draft, but it's possible
> that I missed it - can you point me at that?
> 
> I do agree that if the semantics here were "some otp was used" then
> it would not be necessary to specify exactly which OTP scheme was
> used. But that wasn't how I read what this spec was doing. (Again,
> that could be me getting the wrong end of the stick.)
> 
> S.
> 
> 
>> Many relying parties will be content to know that an OTP has been
>> used in addition to a password.  The distinction between which kind
>> of OTP was used is not useful to them.  Thus, there's a single
>> identifier that can be satisfied in two or more nearly equivalent
>> ways.  I consider this to be a feature - not a bug.
>> 
>> 
>> 
>> Similarly, there's a whole range of nuances between different 
>> fingerprint matching algorithms.  They differ in false positive and
>>  false negative rates over different population samples and also
>> differ based on the kind and model of fingerprint sensor used.
>> Like the OTP case, many RPs will be content to know that a
>> fingerprint match mas made, without delving into and
>> differentiating based on every aspect of the implementation of
>> fingerprint capture and match. Those that want more precision than
>> this can always define new "amr" values.  But "fpt" is fine as is
>> for what I believe will be the 90+% case.
>> 
>> 
>> 
>> Ultimately, the RP is depending upon the Identity Provider to do 
>> reasonable things.  If it didn't trust the IdP to do so, it has no
>>  business using it.  The "amr" value lets the IdP signal to the RP
>>  additional information about what it did, for the cases in which
>> that information is useful to the RP.
>> 
>> 
>> 
>> Reducing this to the point of absurdity, the RP would almost never
>>  care about the make, model, and serial number of the fingerprint 
>> reader or OTP.  Values could be defined to provide that
>> granularity. But making those fine-grained distinctions are not
>> useful in practice.
>> 
>> 
>> 
>> Please consider the existing definitions in light of that reductio
>> ad absurdum.  The existing values only make distinctions that are
>> known to be useful to RPs.  Slicing things more finely than would
>> be used in practice actually hurts interop, rather than helping it,
>> because it would force all RPs to recognize that several or many
>> different values actually mean the same thing to them.
>> 
>> 
>> 
>> -- Mike
>> 
>> 
>> 
>> -----Original Message----- From: Stephen Farrell 
>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Monday, March 6, 2017 2:10
>> 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)
>> 
>> 
>> 
>> 
>> 
>> Hi Mike,
>> 
>> 
>> 
>> Apologies - I updated the discuss ballot text [1] on Feb 28 but 
>> must've not sent it as an email or something. Anyway...
>> 
>> 
>> 
>> [1] 
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ballot/
>>
>>
>>
>>
>> 
On 06/03/17 20:38, Mike Jones wrote:
>> 
>>> Hi Stephen.  The changes in draft -06 were intended to address
>>> your
>> 
>>> DISCUSS points.  Are you satisfied with these changes or are
>>> there
>> 
>>> additional changes you want?  I'm asking partly because it's a
>>> week
>> 
>>> now until the submission cutoff and if additional changes are
>>> needed,
>> 
>>> I'd like to make them this week.
>> 
>> 
>> 
>> So I do think there's still work to be done, may as well copy the
>> new ballot text here:
>> 
>> 
>> 
>> "
>> 
>> I think we still have the problem that the values "defined" here
>> (e.g. "fpt") are under specified to a significant degree. RFC4949
>> does not tell anyone how to achieve interop with "fpt" (nor any of
>> the other cases where you refer to 4949 I think). There is
>> therefore no utility in "defining" "fpt" as it will not achieve
>> interop and in fact is more likely to cause confusion than interop.
>> If the solution of actually defining the meaning of things like
>> "fpt" is not achievable then perhaps it will be better to only
>> define those for which we can get interop ("pwd" and one or two
>> others) and leave the definition of the rest for later. (In saying
>> that I do recall that one of the authors said that there are
>> implementations that use some of these type-names, but the point of
>> RFCs is not to "bless"
>> 
>> such things, but to achieve interop.)
>> 
>> "
>> 
>> 
>> 
>> Cheers,
>> 
>> S.
>> 
>> 
>> 
>>> 
>> 
>>> Thanks, -- Mike
>> 
>>> 
>> 
>>> -----Original Message----- From: Mike Jones
>> 
>>> [mailto:Michael.Jones@microsoft.com] Sent: Tuesday, February 28, 
>>> 2017
>> 
>>> 6:17 PM To: Stephen Farrell 
>>> <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>>; 
>>> Anthony
>> 
>>> Nadalin <tonynad@microsoft.com<mailto:tonynad@microsoft.com>>;
>>> joel jaeggli <joelja@bogus.com<mailto:joelja@bogus.com>>; The
>> 
>>> IESG <iesg@ietf.org<mailto:iesg@ietf.org>> Cc: 
>>> oauth-chairs@ietf.org<mailto:oauth-chairs@ietf.org>;
>> 
>>> draft-ietf-oauth-amr-values@ietf.org<mailto:draft-ietf-oauth-amr-valu
>>>
>>> 
es@ietf.org>;; oauth@ietf.org<mailto:oauth@ietf.org> Subject: RE:
>> 
>>> [OAUTH-WG] Stephen Farrell's Discuss on
>> 
>>> draft-ietf-oauth-amr-values-05: (with DISCUSS)
>> 
>>> 
>> 
>>> Hi Stephen,
>> 
>>> 
>> 
>>> Draft -06 
>>> https://tools.ietf.org/html/draft-ietf-oauth-amr-values-06
>> 
>>> adds references for all of the defined "amr" values.  Thanks for
>> 
>>> taking the time to have a thoughtful discussion.
>> 
>>> 
>> 
>>> -- Mike
>> 
>>> 
>> 
>>> -----Original Message----- From: Stephen Farrell
>> 
>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, February 1, 
>>> 2017
>> 
>>> 4:45 PM To: Mike Jones 
>>> <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>;
>>>
>>> 
Anthony Nadalin
>> 
>>> <tonynad@microsoft.com<mailto:tonynad@microsoft.com>>; joel
>>> jaeggli <joelja@bogus.com<mailto:joelja@bogus.com>>; The IESG
>> 
>>> <iesg@ietf.org<mailto:iesg@ietf.org>> Cc: 
>>> oauth-chairs@ietf.org<mailto:oauth-chairs@ietf.org>;
>> 
>>> draft-ietf-oauth-amr-values@ietf.org<mailto:draft-ietf-oauth-amr-valu
>>>
>>> 
es@ietf.org>;; oauth@ietf.org<mailto: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:35, Mike Jones wrote:
>> 
>>>> You can call me lazy if you want.
>> 
>>> 
>> 
>>> I don't think you're lazy:-) Were I to guess I'd guess that
>>> interop
>> 
>>> for these wasn't a priority and that we're defining them a bit
>>> early
>> 
>>> and a little too generically.
>> 
>>> 
>> 
>>>> Some of them are so well known, such as "password" or "PIN" it
>>>>  didn't
>> 
>>>> seem worthwhile to try to track down a reference.
>> 
>>> 
>> 
>>> Sure, those are fine. The only issues would be if there's a 
>>> string2key
>> 
>>> function somewhere but I don't expect there is in this context.
>> 
>>> 
>> 
>>>> 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.
>> 
>>> 
>> 
>>> I do think it would, esp for cases where there are known
>>> different
>> 
>>> options (e.g. otp) or likely ill-defined or proprietary formats. 
>>> My
>> 
>>> guess is that some biometrics fit that latter but I could be
>>> wrong.
>> 
>>> If they do, then one runs into the problem of having to depend
>>> on
>> 
>>> magic numbers in the encodings or similar to distinguish which
>>> is
>> 
>>> really error prone and likely to lead to what our learned
>>> transport
>> 
>>> chums are calling ossification;-)
>> 
>>> 
>> 
>>> Cheers, S.
>> 
>>> 
>> 
>>> 
>> 
>>>> 
>> 
>>>> 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<mailto:Michael.Jones@microsoft.com>>;
>>>>
>>>> 
Anthony
>> 
>>>> Nadalin <tonynad@microsoft.com<mailto:tonynad@microsoft.com>>; 
>>>> joel jaeggli <joelja@bogus.com<mailto:joelja@bogus.com>>; The
>> 
>>>> IESG <iesg@ietf.org<mailto:iesg@ietf.org>> Cc: 
>>>> oauth-chairs@ietf.org<mailto:oauth-chairs@ietf.org>;
>> 
>>>> draft-ietf-oauth-amr-values@ietf.org<mailto:draft-ietf-oauth-amr-val
>>>>
>>>> 
ues@ietf.org>;; oauth@ietf.org<mailto: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<mailto:stephen.farrell@cs.tcd.ie>>;
>>>>>
>>>>> 
Mike Jones
>> 
>>>>> <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>;
>>>>>
>>>>> 
joel jaeggli <joelja@bogus.com<mailto:joelja@bogus.com>>; The
>> 
>>>>> IESG <iesg@ietf.org<mailto:iesg@ietf.org>> Cc: 
>>>>> oauth-chairs@ietf.org<mailto:oauth-chairs@ietf.org>;
>> 
>>>>> draft-ietf-oauth-amr-values@ietf.org<mailto:draft-ietf-oauth-amr-va
>>>>>
>>>>> 
lues@ietf.org>;; oauth@ietf.org<mailto: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<mailto:Michael.Jones@microsoft.com>>;
>>>>>
>>>>> 
Anthony
>> 
>>>>> Nadalin
>>>>> <tonynad@microsoft.com<mailto:tonynad@microsoft.com>>; joel
>>>>> jaeggli <joelja@bogus.com<mailto:joelja@bogus.com>>;
>> 
>>>>> The IESG <iesg@ietf.org<mailto:iesg@ietf.org>> Cc:
>> 
>>>>> oauth-chairs@ietf.org<mailto:oauth-chairs@ietf.org>; 
>>>>> draft-ietf-oauth-amr-values@ietf.org<mailto:draft-ietf-oauth-amr-va
>>>>>
>>>>> 
lues@ietf.org>;;
>> 
>>>>> oauth@ietf.org<mailto: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<mailto:stephen.farrell@cs.tcd.ie>>;
>>>>>>
>>>>>> 
Mike Jones
>> 
>>>>>> <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>;
>>>>>>
>>>>>> 
joel jaeggli <joelja@bogus.com<mailto:joelja@bogus.com>>;
>> 
>>>>>> The IESG <iesg@ietf.org<mailto:iesg@ietf.org>> Cc: 
>>>>>> oauth-chairs@ietf.org<mailto:oauth-chairs@ietf.org>;
>> 
>>>>>> draft-ietf-oauth-amr-values@ietf.org<mailto:draft-ietf-oauth-amr-v
>>>>>>
>>>>>> 
alues@ietf.org>;; oauth@ietf.org<mailto: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-recognitio
>>>>>>
>>>>>> 
n
>> 
>>>>>> -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<mailto:Michael.Jones@microsoft.com>>;
>>>>>>
>>>>>> 
joel
>> 
>>>>>> jaeggli <joelja@bogus.com<mailto:joelja@bogus.com>>; The
>>>>>> IESG <iesg@ietf.org<mailto:iesg@ietf.org>> Cc:
>> 
>>>>>> oauth-chairs@ietf.org<mailto:oauth-chairs@ietf.org>; 
>>>>>> draft-ietf-oauth-amr-values@ietf.org<mailto:draft-ietf-oauth-amr-v
>>>>>>
>>>>>> 
alues@ietf.org>;;
>> 
>>>>>> oauth@ietf.org<mailto: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<mailto:joelja@bogus.com>>; The IESG 
>>>>>>> <iesg@ietf.org<mailto:iesg@ietf.org>> Cc:
>> 
>>>>>>> oauth-chairs@ietf.org<mailto:oauth-chairs@ietf.org>; 
>>>>>>> draft-ietf-oauth-amr-values@ietf.org<mailto:draft-ietf-oauth-amr-values@ietf.org>;
>>
>>>>>>>
>>>>>>> 
oauth@ietf.org<mailto: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.
>> 
>>>>>>> 
>> 
>>>>>>> 
>> 
>>>>>>>>> 
>> 
>>>>>>>>> 
>> 
>>>>>>>>> 
>> 
>>>>>>>> 
>> 
>>>>>>>> 
>> 
>>>>>>> 
>> 
>>>>>> 
>> 
>>>>> 
>> 
>>>> 
>> 
>>> 
>> 
>> 
>