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

Stephen Farrell <> Wed, 01 February 2017 22:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 871DA1295C6; Wed, 1 Feb 2017 14:25:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.499
X-Spam-Status: No, score=-7.499 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=-3.199, 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 6l5F_DuWB_4k; Wed, 1 Feb 2017 14:25:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCB181294A5; Wed, 1 Feb 2017 14:25:52 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27535BE5B; Wed, 1 Feb 2017 22:25:50 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id isxMEEWYnTO0; Wed, 1 Feb 2017 22:25:48 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id B8784BE58; Wed, 1 Feb 2017 22:25:47 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1485987948; bh=U00HrQZ66ZR/1sf/BWMSJQCIWsn1cpb8kggb4OJWRtE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=eiuZzBHopT215K/CHa2a6O7DYAxKka45N8T9uArjX8D4j2QtWxlw33Bi6DjDL50wh DgpMsJMnAQVjWodKQbCgJ8ZoVcd4WgZxpTmbLgqnwYM6yLOcpGGLzwigQR2DlJ/CYh przmvt0epRF+ct4YbHHVQT0oYaChlxBPDLJhYGcs=
To: Mike Jones <>, joel jaeggli <>, The IESG <>
References: <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Wed, 1 Feb 2017 22:25:47 +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: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040900000301060103060202"
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 22:25:55 -0000

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

And the same for all the others...


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