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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D411E129612; Wed, 1 Feb 2017 16:21:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TfLfEJu77ARq; Wed, 1 Feb 2017 16:21:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 175C2129600; Wed, 1 Feb 2017 16:21:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wbnN7bdTYmmNlbPdbXSAEPdJmnk9775uDB1+OzdntuQ=; b=iioGLhWiL4g2xj97nJW1x2kUjM30eQwo+DgfnIEMdezw3oqs3NMNae9b6CWKrobqANDLPGPQLTnZytaHd5zF1yKOy6L6q/5nMKxkPLrcRZL7nnc3g21V/B252zM5SeRBfvebHQ0WcvrIwhCMCYu5ORcVxb3BZT2rCKP6RvX0LCg=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Thu, 2 Feb 2017 00:21:42 +0000
Received: from ([]) by ([]) with mapi id 15.01.0860.026; Thu, 2 Feb 2017 00:21:42 +0000
From: Anthony Nadalin <>
To: Stephen Farrell <>, Mike Jones <>, joel jaeggli <>, The IESG <>
Thread-Topic: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Date: Thu, 2 Feb 2017 00:21:42 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
x-ms-office365-filtering-correlation-id: 39d8deca-5a0f-47c5-4754-08d44b017691
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR03MB2355;
x-microsoft-exchange-diagnostics: 1; BN3PR03MB2355; 7:gXGzsJcUdU6Gwz6G0lvfd6MY7kFXCV/CZHEGfS6QJmq4tnPwzzvISYadQ79Q7RrWawfF2wVblqD1TqSpq+0nYbw+mDtycSKqL7xHQDYPlW6GewGQZbKGkEI5V8XIlLmrUqF/qEb3AmN+pI/nSb++CAPbBVaI3mRpBNg+Z3+LxyAoeRQ0UgRhp9VCDQ9665oiTLDpMQUxA2rEUU1p0HkYWMKSp52vHgXQnAoBBcNSQZ35sejtgHL0CxmmWjQa9171KROjkBLc2XJ4OdHtSRBNS5Ew1U3GuEThHJvYfzcWBTymK+9WQWDXIonQLmUuXyy0x5qvXjGhG5cNtswAwTtklJsQO5g9HtvrS9poBI7XMrQNok6JMPq59Q4/N98v+Yv0wlVSFYgai+jZuqHtFnYqddc3dTk50Yy2BRhodVmtkaNAchezQinNTT0bLEu4WOeLamykxn/oipFLeFP50z0fCDFS5ndodXvzVrVGklgoJG4S0KR6eNunnmhQcTXsb8ehiz1g1u5SDFw1ZCSiykKTT0cVKCcC1McGU6HOAf/lcRpHXTQona9HVBB3VHly7CwZ
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(32856632585715)(120809045254105);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(20161123564025)(6042181)(6072148); SRVR:BN3PR03MB2355; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2355;
x-forefront-prvs: 02065A9E77
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(24454002)(40224003)(51914003)(189002)(13464003)(199003)(51444003)(230783001)(77096006)(2900100001)(3846002)(2421001)(102836003)(5660300001)(25786008)(3280700002)(33656002)(10090500001)(2906002)(38730400001)(229853002)(4326007)(8990500004)(53936002)(92566002)(966004)(122556002)(105586002)(106356001)(106116001)(6116002)(74316002)(8676002)(99286003)(50986999)(8936002)(7736002)(76176999)(54356999)(305945005)(86612001)(68736007)(5005710100001)(10290500002)(81156014)(81166006)(1511001)(6306002)(86362001)(6506006)(66066001)(9686003)(3660700001)(6436002)(7696004)(2950100002)(2561002)(55016002)(5001770100001)(101416001)(189998001)(97736004)(54906002)(93886004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2355;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 00:21:42.0323 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2355
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Feb 2017 00:21:47 -0000

The code point is that Windows Hello protocol supports three types of biometric authentication: fingerprint, face and iris, we need to distinguish between eye, retina and iris. There are windows devices that do retina also, like windows phones, we have now gone to iris after the NIST testing and thus want tto make sure there is a way to distinguish during the  authentication since the iris scan reduces the probability of error

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

Hi Tony,

On 02/02/17 00:10, Anthony Nadalin wrote:
> 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

Sorry, but that doesn't help me (at first glance anyway). If
there's a reference that'd garner us interop, then great, just
add it to match the codepoint. If there's not, I don't see why
adding a codepoint is useful. (Esp. if we're at the stage of
testing "various iris devices" that I would guess do not get
us interop.)

Am I missing something?


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