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

Mike Jones <> Wed, 01 February 2017 17:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9F821294DF; Wed, 1 Feb 2017 09:01:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.157
X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k1fnrxFCZUkB; Wed, 1 Feb 2017 09:01:01 -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 CBD421294E8; Wed, 1 Feb 2017 09:00:49 -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=CBCJr0443dN5vq91AGps9dv3DLqfUb2fHt7/5a8ewpw=; b=Hv7eLt+ZZdIhfaTldXAvEI5zwgR9Z2bTIx7EHdfAbUuVOLb3O8HF0/lgUZWb+tnIUNYJs174Js+ioMuva7xNQy5WZB6zK0XUBHzCIjWXqluSFRr9KrWNpWGcFlfDOCvp1Jz/gQ731t+WEQjw//4ntpcvrTru0+PmCKOAIuKc31M=
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; Wed, 1 Feb 2017 17:00:48 +0000
Received: from ([]) by ([]) with mapi id 15.01.0874.021; Wed, 1 Feb 2017 17:00:48 +0000
From: Mike Jones <>
To: Stephen Farrell <>, joel jaeggli <>, The IESG <>
Thread-Topic: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Date: Wed, 1 Feb 2017 17:00:47 +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-ms-office365-filtering-correlation-id: bb5b53a1-f4f6-4f86-7644-08d44ac3ded0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR03MB2354;
x-microsoft-exchange-diagnostics: 1; BN3PR03MB2354; 7:tdts7GLzKM1oBtXBFdu9JN6xIagCytMSJ3g0gOSg2NL9aWRachhm4bvcGdOMGyLbe2tMvq5Tp4ufiI32LPAGGAkE7yeIN0gNYDqb95krENFXIw0zmamXUcD+LY+3x2j8FFH8/ZPPRp2yX33agoR7o57bhrC8SeS+4TpbChDmu9W1TsWez5La5nxZWee/kqvxl26gcBwPGHPCwX+XbZbEPvyWsbOAmyrfFTAmEkBa9tQm0o+hy0JGAhtvJ4HhGK54T8BhwdAo74I4nHSfyl6p6Mva7wNZead0CW4CQ1UwQH6SuGf83KcosQKZpkI7KwWK/iomFERg21WBogfm++d+vo6bqYWl87EHOGK/xKD9dCjuebw2HLA1l5XI9ut1RP1EuweHpRsSjitKF/eB97A+QixBlNSTsyLIsyr4ybH/smPa9mdANpuvohI1d1wuhmkXAV1RSMiPZWN/pCpTfFinCW4bxMgb8hffBaPFW9venn2iYuoBHnffUI+B+mwwQvSfThlKZ/K16hqEuFdqYJYWvLyXniQroqifGI9zf0a62wL15X3xAeyT5zoJxrfRJaFc
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(120809045254105);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558025)(6072148); SRVR:BN3PR03MB2354; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2354;
x-forefront-prvs: 0205EDCD76
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39840400002)(39450400003)(39410400002)(51444003)(51914003)(377454003)(40224003)(189002)(199003)(24454002)(13464003)(6116002)(10090500001)(53936002)(97736004)(5001770100001)(3846002)(3280700002)(8990500004)(5005710100001)(2906002)(4326007)(2950100002)(5660300001)(106116001)(102836003)(7736002)(10290500002)(230783001)(305945005)(106356001)(105586002)(7696004)(6306002)(54356999)(9686003)(54906002)(3660700001)(25786008)(76176999)(6436002)(77096006)(229853002)(6506006)(74316002)(189998001)(55016002)(38730400001)(99286003)(68736007)(8676002)(101416001)(86362001)(122556002)(81156014)(92566002)(86612001)(81166006)(8936002)(50986999)(33656002)(66066001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2354;; 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: 01 Feb 2017 17:00:48.0662 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2354
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: Wed, 01 Feb 2017 17:01:03 -0000

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

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