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

From: Mike Jones <[email-masked]>
Date: Mon, 6 Mar 2017 20:38:01 +0000

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.

				Thanks,
				-- Mike

-----Original Message-----
From: Mike Jones [mailto:[email-masked]] 
Sent: Tuesday, February 28, 2017 6:17 PM
To: Stephen Farrell <[email-masked]>; Anthony Nadalin <[email-masked]>; joel jaeggli <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]] 
Sent: Wednesday, February 1, 2017 4:45 PM
To: Mike Jones <[email-masked]>; Anthony Nadalin <[email-masked]>; joel jaeggli <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]] Sent: Wednesday, February 1, 2017
> 4:31 PM To: Mike Jones <[email-masked]>; Anthony Nadalin
> <[email-masked]>; joel jaeggli <[email-masked]>; The IESG
> <[email-masked]> Cc: [email-masked];
> [email-masked]; [email-masked] 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 
>> <[email-masked]>; Mike Jones 
>> <[email-masked]>; joel jaeggli <[email-masked]>;
>> The IESG <[email-masked]> Cc: [email-masked]; 
>> [email-masked]; [email-masked] 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:[email-masked]] Sent: Wednesday, February 1,
>> 2017 4:24 PM To: Mike Jones <[email-masked]>; Anthony
>> Nadalin <[email-masked]>; joel jaeggli <[email-masked]>;
>> The IESG <[email-masked]> Cc: [email-masked]; 
>> [email-masked]; [email-masked] 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 
>>> <[email-masked]>; Mike Jones 
>>> <[email-masked]>; joel jaeggli <[email-masked]>; 
>>> The IESG <[email-masked]> Cc: [email-masked]; 
>>> [email-masked]; [email-masked] 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:[email-masked]] Sent: Wednesday, February 1, 
>>> 2017 2:26 PM To: Mike Jones <[email-masked]>; joel 
>>> jaeggli <[email-masked]>; The IESG <[email-masked]> Cc: 
>>> [email-masked]; [email-masked]; 
>>> [email-masked] 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:[email-masked]] On Behalf Of Stephen Farrell 
>>>> Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli 
>>>> <[email-masked]>; The IESG <[email-masked]> Cc: 
>>>> [email-masked]; [email-masked]; 
>>>> [email-masked] 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.
>>>> 
>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 6 Mar 2017 22:09:59 +0000

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:[email-masked]] Sent: Tuesday, February 28, 2017
> 6:17 PM To: Stephen Farrell <[email-masked]>; Anthony
> Nadalin <[email-masked]>; joel jaeggli <[email-masked]>; The
> IESG <[email-masked]> Cc: [email-masked];
> 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
> 
> 4:45 PM To: Mike Jones <[email-masked]>; Anthony Nadalin
> 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
>> 
>> 2017 4:31 PM To: Mike Jones <[email-masked]>; Anthony
>>> 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).
>> 
>>> 2017 4:24 PM To: Mike Jones <[email-masked]>;
>>> Anthony Nadalin <[email-masked]>; joel jaeggli
>>>> Stephen, the sets of initial values were chosen from those
>>>> used in practice by Microsoft and Google in real deployments.
>>> 
>>>> 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.
>>>> 
>>>> Reference Name (such as "otp") is defined.  In all cases for
>>>> the initial values, this is the RFC-to-be, so the registry 
>>>> 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 
>>>> [email-masked]; [email-masked] Subject:
>>>> RE: [OAUTH-WG] Stephen Farrell's Discuss on 
>>>> 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 
>>>>  2017 2:26 PM To: Mike Jones <[email-masked]>;
>>>> joel jaeggli <[email-masked]>; The IESG <[email-masked]> Cc: 
>>>>> 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.
>>>> 
>>>>  seems right. (Mentioning it as a possible future entry would
>>>> be fine.)
>>>> 
>>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>>> 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
>>>>> 
>>>>>>> Stephen Farrell has entered the following ballot
>>>>>>> position for draft-ietf-oauth-amr-values-05: 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.
>>>>>> 
>>>>>> needs to adhere to the rules for further allocations in
>>>>>> order to prepoulate the registry. that is perhaps an appeal
>>>>>> to future consistency.
>>>>> 
>>>>> and yet only have one value. That seems a bit broken to me,
>>>>> so the discuss isn't really about the formalism.
>>>>> 
>>>>> S.
>>>>> 
>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 6 Mar 2017 22:34:03 +0000

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.  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:[email-masked]]
Sent: Monday, March 6, 2017 2:10 PM
To: Mike Jones <[email-masked]>; Anthony Nadalin <[email-masked]>; joel jaeggli <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
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...

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

"

Cheers,

S.

> 6:17 PM To: Stephen Farrell <[email-masked]<mailto:[email-masked]>>; Anthony

> Nadalin <[email-masked]<mailto:[email-masked]>>; joel jaeggli <[email-masked]<mailto:[email-masked]>>; The

> IESG <[email-masked]<mailto:[email-masked]>> Cc: [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Subject: RE:

> 4:45 PM To: Mike Jones <[email-masked]<mailto:[email-masked]>>; Anthony Nadalin

> <[email-masked]<mailto:[email-masked]>>; joel jaeggli <[email-masked]<mailto:[email-masked]>>; The IESG

> <[email-masked]<mailto:[email-masked]>> Cc: [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Subject: Re:

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

>> 2017 4:31 PM To: Mike Jones <[email-masked]<mailto:[email-masked]>>; Anthony

>> Nadalin <[email-masked]<mailto:[email-masked]>>; joel jaeggli <[email-masked]<mailto:[email-masked]>>; The

>> IESG <[email-masked]<mailto:[email-masked]>> Cc: [email-masked]<mailto:[email-masked]>;

>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Subject: Re:

>>> <[email-masked]<mailto:[email-masked]>>; Mike Jones

>>> <[email-masked]<mailto:[email-masked]>>; joel jaeggli <[email-masked]<mailto:[email-masked]>>; The

>>> IESG <[email-masked]<mailto:[email-masked]>> Cc: [email-masked]<mailto:[email-masked]>;

>>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Subject: RE:

>>> 2017 4:24 PM To: Mike Jones <[email-masked]<mailto:[email-masked]>>; Anthony

>>> Nadalin <[email-masked]<mailto:[email-masked]>>; joel jaeggli <[email-masked]<mailto:[email-masked]>>;

>>> The IESG <[email-masked]<mailto:[email-masked]>> Cc:

>>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

>>> [email-masked]<mailto:[email-masked]> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on

>>>> Stephen, the sets of initial values were chosen from those used in

>>>> practice by Microsoft and Google in real deployments.

>>> deployments? What if I wanted to write code that'd interop with msft

>>> or google?

>>>> distinction between TOTP and HOTP is important.  Thus, having "otp"

>>>> now makes sense, where having "hotp" and "totp"

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

>>>> for the remaining values that don't currently have them. (Anyone

>>>> got a good reference for password or PIN to suggest, for instance?)

>>>> <[email-masked]<mailto:[email-masked]>>; Mike Jones

>>>> <[email-masked]<mailto:[email-masked]>>; joel jaeggli <[email-masked]<mailto:[email-masked]>>;

>>>> The IESG <[email-masked]<mailto:[email-masked]>> Cc: [email-masked]<mailto:[email-masked]>;

>>>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Subject:

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

>>>>  2017 2:26 PM To: Mike Jones <[email-masked]<mailto:[email-masked]>>; joel

>>>> jaeggli <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>> Cc:

>>>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

>>>> [email-masked]<mailto:[email-masked]> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on

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

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

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

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

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

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

>>>>> <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>> Cc:

>>>>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

>>>>>  [email-masked]<mailto:[email-masked]> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss

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

>>>>>>> The document, along with other ballot positions, can be found

>>>>>>> here:

>>>>>>> ----------------------------------------------------------------

>>>>>>> -----

-

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 6 Mar 2017 22:38:53 +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
> 
> 
> 
> [mailto:[email-masked]] Sent: Monday, March 6, 2017 2:10
> PM To: Mike Jones <[email-masked]>; Anthony Nadalin
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ballot/
> 
> 
> 
> 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"
> 
>> 6:17 PM To: Stephen Farrell
>> <[email-masked]<mailto:[email-masked]>>;
>> Anthony
> 
>> Nadalin <[email-masked]<mailto:[email-masked]>>; joel
>> jaeggli <[email-masked]<mailto:[email-masked]>>; The
> 
>> IESG <[email-masked]<mailto:[email-masked]>> Cc:
>> [email-masked]<mailto:[email-masked]>;
> 
>> [email-masked]<mailto:[email-masked]>;
>> [email-masked]<mailto:[email-masked]> Subject: RE:
> 
>> Draft -06
>> https://tools.ietf.org/html/draft-ietf-oauth-amr-values-06
> 
>> 2017
>> 4:45 PM To: Mike Jones
>> <[email-masked]<mailto:[email-masked]>>;
>> Anthony Nadalin
> 
>> <[email-masked]<mailto:[email-masked]>>; joel jaeggli
>> <[email-masked]<mailto:[email-masked]>>; The IESG
> 
>> <[email-masked]<mailto:[email-masked]>> Cc:
>> [email-masked]<mailto:[email-masked]>;
> 
>> [email-masked]<mailto:[email-masked]>;
>> [email-masked]<mailto:[email-masked]> Subject: Re:
> 
>> interop
>>> didn't
>> string2key
>>> the
>>> 2017 4:31 PM To: Mike Jones
>>> <[email-masked]<mailto:[email-masked]>>;
>>> Anthony
> 
>>> Nadalin <[email-masked]<mailto:[email-masked]>>;
>>> joel jaeggli <[email-masked]<mailto:[email-masked]>>; The
> 
>>> IESG <[email-masked]<mailto:[email-masked]>> Cc:
>>> [email-masked]<mailto:[email-masked]>;
> 
>>> [email-masked]<mailto:[email-masked]>;
>>> [email-masked]<mailto:[email-masked]> Subject: Re:
> 
>>> what
>>>> Wednesday,
>>>> <[email-masked]<mailto:[email-masked]>>;
>>>> joel jaeggli <[email-masked]<mailto:[email-masked]>>; The
> 
>>>> IESG <[email-masked]<mailto:[email-masked]>> Cc:
>>>> [email-masked]<mailto:[email-masked]>;
> 
>>>> [email-masked]<mailto:[email-masked]>;
>>>> [email-masked]<mailto:[email-masked]> Subject: RE:
> 
>>>> 2017 4:24 PM To: Mike Jones
>>>> <[email-masked]<mailto:[email-masked]>>;
>>>> Anthony
> 
>>>> Nadalin <[email-masked]<mailto:[email-masked]>>;
>>>> joel jaeggli <[email-masked]<mailto:[email-masked]>>;
> 
>>>> [email-masked]<mailto:[email-masked]>;
>>>> [email-masked]<mailto:[email-masked]>;
>
>>>>> used in
>>>> msft
>>>>> an
>>>>> "otp"
>>>>> the
>>>>> instructions
>>>>> references
>>>>> (Anyone
>>>>> <[email-masked]<mailto:[email-masked]>>;
>>>>> joel jaeggli <[email-masked]<mailto:[email-masked]>>;
> 
>>>>> [email-masked]<mailto:[email-masked]>;
> 
>>>>> [email-masked]<mailto:[email-masked]>;
>>>>> [email-masked]<mailto:[email-masked]> Subject:
> 
>>>>> use of
>>>>> 2017 2:26 PM To: Mike Jones
>>>>> <[email-masked]<mailto:[email-masked]>>;
>>>>> joel
> 
>>>>> jaeggli <[email-masked]<mailto:[email-masked]>>; The IESG
>>>>> <[email-masked]<mailto:[email-masked]>> Cc:
> 
>>>>> [email-masked]<mailto:[email-masked]>;
>>>>> [email-masked]<mailto:[email-masked]>;
>
>>>>>> very
>>>>>> which the
>>>>> be
>>>>>> been
>>>>>> balancing
>>>>>> number
>>>>> expected
>>>>> that,
>>>>>> reference is
>>>>>> think
>>>>>> <[email-masked]<mailto:[email-masked]>>; The IESG
>>>>>> <[email-masked]<mailto:[email-masked]>> Cc:
> 
>>>>>> [email-masked]<mailto:[email-masked]>;
>>>>>> [email-masked]<mailto:[email-masked]>;
>
>>>>>>>> position for
>>>>>>>> found
>>>>>>>> to a
>>>>>>> needs to
>>>>>> impact

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Mar 2017 17:17:20 +0000

You're right, Stephen.  Re-reading the spec, it doesn't say that, and it should.  Sometimes it takes someone giving a spec a fresh read to uncover things that the authors understood and intended but failed to be captured in the text.  This is such a case - so thanks.

I'll add this information, which is necessary to understand the intent, and then republish.

				-- Mike

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Monday, March 6, 2017 2:39 PM
To: Mike Jones <[email-masked]>; Anthony Nadalin <[email-masked]>; joel jaeggli <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

Hi Mike,

On 06/03/17 22:34, Mike Jones wrote:
> 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.

> 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.
> 
> 
> 
> 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.
> But making those fine-grained distinctions are not useful in practice.
> 
> 
> 
> 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
> 
> 
> 
> [mailto:[email-masked]] Sent: Monday, March 6, 2017 2:10 PM 
> To: Mike Jones <[email-masked]>; Anthony Nadalin 
> 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"
> 
>> [email-masked]<mailto:draft-ietf-oauth-amr-valu
>> [email-masked]>; [email-masked]<mailto:[email-masked]> Subject: RE:
> 
>> [email-masked]<mailto:draft-ietf-oauth-amr-valu
>> [email-masked]>; [email-masked]<mailto:[email-masked]> Subject: Re:
> 
>>> [email-masked]<mailto:draft-ietf-oauth-amr-val
>>> [email-masked]>; [email-masked]<mailto:[email-masked]> Subject: Re:
> 
>>>> Mike Jones
>>>> [email-masked]<mailto:draft-ietf-oauth-amr-va
>>>> [email-masked]>; [email-masked]<mailto:[email-masked]> Subject: RE:
> 
>>>>> Mike Jones
>>>>> [email-masked]<mailto:draft-ietf-oauth-amr-v
>>>>> [email-masked]>; [email-masked]<mailto:[email-masked]> Subject:
> 
>>>>> of
>>>>>> [OAUTH-WG] Stephen Farrell's Discuss
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Mar 2017 18:10:38 +0000

On 07/03/17 17:17, Mike Jones wrote:
> You're right, Stephen.  Re-reading the spec, it doesn't say that, and
> it should.  Sometimes it takes someone giving a spec a fresh read to
> uncover things that the authors understood and intended but failed to
> be captured in the text.  This is such a case - so thanks.
> 

Ah good, that explains the disconnect.

Cheers,
S.

> [mailto:[email-masked]] Sent: Monday, March 6, 2017 2:39
> 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.
>> 
>> 
>> 
>> 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.
>> 
>> 
>> 
>>  additional information about what it did, for the cases in which
>> that information is useful to the RP.
>> 
>> 
>> 
>> 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
>> 
>> 
>> 
On 06/03/17 20:38, Mike Jones wrote:
>> 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"
>> 
Anthony Nadalin
>> 
>>> <[email-masked]<mailto:[email-masked]>>; joel
[email-masked]>; [email-masked]<mailto:[email-masked]> Subject: Re:
>>> different
Anthony
Mike Jones
Anthony
>> 
>>>>> Nadalin
>>>>> <[email-masked]<mailto:[email-masked]>>; joel
>>>>> jaeggli <[email-masked]<mailto:[email-masked]>>;
>> 
[email-masked]>;
Mike Jones
[email-masked]>; [email-masked]<mailto:[email-masked]> Subject:
>>>>>> http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognitio
>>>>>>
>>>>>> 
n
joel
>>>>>> [email-masked]<mailto:draft-ietf-oauth-amr-v
[email-masked]>;
-----

---

From: Mike Jones <[email-masked]>
Date: Thu, 9 Mar 2017 05:53:15 +0000

Hi Stephen,

I've added text to the introduction explaining that the values are intended to provide identifiers for families of closely-related authentication methods, based on our discussion of this topic.  See the diffs at https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-amr-values-07.  Hopefully this clarifies things sufficiently to satisfy the intent of your DISCUSS, Stephen.  Let me know.

I also updated the MODRNA Authentication Profile reference.

				Thanks again,
				-- Mike

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, March 7, 2017 10:11 AM
To: Mike Jones <[email-masked]>; Anthony Nadalin <[email-masked]>; joel jaeggli <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

Cheers,
S.

> [mailto:[email-masked]] Sent: Monday, March 6, 2017 2:39 PM 
> 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.
> 
> 
>> 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.
>> 
>> 
>> 
On 06/03/17 20:38, Mike Jones wrote:
>> 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
>>> u
Anthony Nadalin
>>> u
Anthony
>>>> l
Mike Jones
>>>>> a
Anthony
>>>>> a
[email-masked]>;
>>>>>> in
Mike Jones
n
joel
[email-masked]>;
>>>>>>> and
[email-masked]<mailto:[email-masked]> Subject: Re:
>>>>>>>>> reply
-----
>>>>>>>>> added