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, 06 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. > >>>>>> > >>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >
- [OAUTH-WG] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… joel jaeggli
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Mike Jones
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Anthony Nadalin
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Anthony Nadalin
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Mike Jones
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Anthony Nadalin
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Mike Jones
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Mike Jones
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Manger, James
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Mike Jones
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Mike Jones
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Mike Jones
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Mike Jones
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Mike Jones