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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 06 March 2017 22:39 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 F1BD61294A6; Mon, 6 Mar 2017 14:39:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 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] 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 R7q2kyBQOcxF; Mon, 6 Mar 2017 14:39:04 -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 B22E9129493; Mon, 6 Mar 2017 14:39:03 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5369EBEBB; Mon, 6 Mar 2017 22:39:01 +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 Jx0sHdsBpP9B; Mon, 6 Mar 2017 22:38:55 +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 38221BED5; Mon, 6 Mar 2017 22:38:54 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1488839935; bh=uRCsquwKlqqq3+p8dB5jEKfx538gnH6APCkuL1uD+cE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=tP4LFt8CTTm0kKRp1l6X3nI7KYhALWe/TNMdnfUHXzJkMZSxs9K2ssQ08Il7rf3BY 9upi7i0kHuNFNtEgxocyl/GXLmDLk5T55flxm8PhKAx2Fg1EwNWc3tYdYsvpd7DeOp ro1kFkjjD1427rQN5ji+Bsv6raNQk/bRoZORwOcQ=
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> <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> <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>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <a78de3c1-7d73-8147-8540-0bc23fca366d@cs.tcd.ie>
Date: Mon, 6 Mar 2017 22:38:53 +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: <CY4PR21MB050481D8CF7B8551D21F38A8F52C0@CY4PR21MB0504.namprd21.prod.outlook.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GiwLTeID5MhXCOgCfSqk9XNVl6PT3tF4t"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/73blVlXWKhQGAnGJ4DnrDvhKTs4>
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: Mon, 06 Mar 2017 22:39:07 -0000

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-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)
> 
>> 
> 
>> 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-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 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-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 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-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)
> 
>>>> 
> 
>>>> 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-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 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-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)
> 
>>>>> 
> 
>>>>> 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<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-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)
> 
>>>>> 
> 
>>>>> 
> 
>>>>> 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.
> 
>>>>>> 
> 
>>>>>> 
> 
>>>>>>>> 
> 
>>>>>>>> 
> 
>>>>>>>> 
> 
>>>>>>> 
> 
>>>>>>> 
> 
>>>>>> 
> 
>>>>> 
> 
>>>> 
> 
>>> 
> 
>> 
> 
>