Discussion:
[OAUTH-WG] Stephen Farrell's Discuss on
Stephen Farrell
2017-01-31 16:26:24 UTC
Permalink
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.
joel jaeggli
2017-02-01 14:58:54 UTC
Permalink
Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
----------------------------------------------------------------------
----------------------------------------------------------------------
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.
Stephen Farrell
2017-02-01 15:02:56 UTC
Permalink
Post by joel jaeggli
Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
----------------------------------------------------------------------
----------------------------------------------------------------------
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.
Mike Jones
2017-02-01 17:00:47 UTC
Permalink
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 [mailto:oauth-***@ietf.org] On Behalf Of Stephen Farrell
Sent: Wednesday, February 1, 2017 7:03 AM
To: joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
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.
Stephen Farrell
2017-02-01 22:25:47 UTC
Permalink
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
-
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
---------------------------------------------------------------------
-
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Anthony Nadalin
2017-02-02 00:10:22 UTC
Permalink
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:***@cs.tcd.ie]
Sent: Wednesday, February 1, 2017 2:26 PM
To: Mike Jones <***@microsoft.com>; joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)


Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
-
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
---------------------------------------------------------------------
-
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Stephen Farrell
2017-02-02 00:14:56 UTC
Permalink
Hi Tony,
Post by Anthony Nadalin
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
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?

Cheers,
S.
Post by Anthony Nadalin
-----Original Message----- From: Stephen Farrell
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
-
Post by Anthony Nadalin
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
---------------------------------------------------------------------
-
Post by Anthony Nadalin
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Anthony Nadalin
2017-02-02 00:21:42 UTC
Permalink
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 [mailto:***@cs.tcd.ie]
Sent: Wednesday, February 1, 2017 4:15 PM
To: Anthony Nadalin <***@microsoft.com>; Mike Jones <***@microsoft.com>; joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)


Hi Tony,
Post by Anthony Nadalin
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
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?

Cheers,
S.
Post by Anthony Nadalin
-----Original Message----- From: Stephen Farrell
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
-
Post by Anthony Nadalin
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
---------------------------------------------------------------------
-
Post by Anthony Nadalin
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Mike Jones
2017-02-02 00:21:45 UTC
Permalink
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.

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 <***@cs.tcd.ie>; Mike Jones <***@microsoft.com>; joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@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:***@cs.tcd.ie]
Sent: Wednesday, February 1, 2017 2:26 PM
To: Mike Jones <***@microsoft.com>; joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)


Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
-
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
---------------------------------------------------------------------
-
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Stephen Farrell
2017-02-02 00:24:05 UTC
Permalink
Post by Mike Jones
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.
Post by Mike Jones
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
[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
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
---------------------------------------------------------------------
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Anthony Nadalin
2017-02-02 00:27:12 UTC
Permalink
We have interoped between FIDO authenticators vendors and Windows Hello

-----Original Message-----
From: Stephen Farrell [mailto:***@cs.tcd.ie]
Sent: Wednesday, February 1, 2017 4:24 PM
To: Mike Jones <***@microsoft.com>; Anthony Nadalin <***@microsoft.com>; joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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
[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
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
---------------------------------------------------------------------
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Mike Jones
2017-02-02 00:28:49 UTC
Permalink
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.

-----Original Message-----
From: Anthony Nadalin
Sent: Wednesday, February 1, 2017 4:27 PM
To: Stephen Farrell <***@cs.tcd.ie>; Mike Jones <***@microsoft.com>; joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@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:***@cs.tcd.ie]
Sent: Wednesday, February 1, 2017 4:24 PM
To: Mike Jones <***@microsoft.com>; Anthony Nadalin <***@microsoft.com>; joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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
[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
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
---------------------------------------------------------------------
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Stephen Farrell
2017-02-02 00:31:14 UTC
Permalink
Post by Mike Jones
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
Post by Mike Jones
-----Original Message----- From: Anthony Nadalin Sent: Wednesday,
February 1, 2017 4:27 PM To: Stephen Farrell
[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
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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
[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
Post by Mike Jones
Post by Mike Jones
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
Post by Mike Jones
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
---------------------------------------------------------------------
-
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Mike Jones
2017-02-02 00:35:33 UTC
Permalink
You can call me lazy if you want. Some of them are so well known, such as "password" or "PIN" it didn't seem worthwhile to try to track down a reference. 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.

Best wishes,
-- Mike

-----Original Message-----
From: Stephen Farrell [mailto:***@cs.tcd.ie]
Sent: Wednesday, February 1, 2017 4:31 PM
To: Mike Jones <***@microsoft.com>; Anthony Nadalin <***@microsoft.com>; joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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
Post by Mike Jones
-----Original Message----- From: Anthony Nadalin Sent: Wednesday,
February 1, 2017 4:27 PM To: Stephen Farrell
[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
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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
[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
Post by Mike Jones
Post by Mike Jones
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
Post by Mike Jones
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
---------------------------------------------------------------------
-
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Stephen Farrell
2017-02-02 00:45:01 UTC
Permalink
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
Best wishes, -- Mike
-----Original Message----- From: Stephen Farrell
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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
Post by Mike Jones
-----Original Message----- From: Anthony Nadalin Sent: Wednesday,
February 1, 2017 4:27 PM To: Stephen Farrell
[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
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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
[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
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
Post by Mike Jones
Post by Mike Jones
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
---------------------------------------------------------------------
-
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Mike Jones
2017-03-01 02:16:52 UTC
Permalink
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:***@cs.tcd.ie]
Sent: Wednesday, February 1, 2017 4:45 PM
To: Mike Jones <***@microsoft.com>; Anthony Nadalin <***@microsoft.com>; joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
Best wishes, -- Mike
-----Original Message----- From: Stephen Farrell
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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
Post by Mike Jones
-----Original Message----- From: Anthony Nadalin Sent: Wednesday,
February 1, 2017 4:27 PM To: Stephen Farrell
[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
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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
[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
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
Post by Mike Jones
Post by Mike Jones
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
---------------------------------------------------------------------
-
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Mike Jones
2017-03-06 20:38:01 UTC
Permalink
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:***@microsoft.com]
Sent: Tuesday, February 28, 2017 6:17 PM
To: Stephen Farrell <***@cs.tcd.ie>; Anthony Nadalin <***@microsoft.com>; joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@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:***@cs.tcd.ie]
Sent: Wednesday, February 1, 2017 4:45 PM
To: Mike Jones <***@microsoft.com>; Anthony Nadalin <***@microsoft.com>; joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
Best wishes, -- Mike
-----Original Message----- From: Stephen Farrell
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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
Post by Mike Jones
-----Original Message----- From: Anthony Nadalin Sent: Wednesday,
February 1, 2017 4:27 PM To: Stephen Farrell
[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
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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
[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
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
Post by Mike Jones
Post by Mike Jones
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
---------------------------------------------------------------------
-
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Stephen Farrell
2017-03-06 22:09:59 UTC
Permalink
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/
Post by Mike Jones
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.
Post by Mike Jones
Thanks, -- Mike
-----Original Message----- From: Mike Jones
[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
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
Best wishes, -- Mike
-----Original Message----- From: Stephen Farrell
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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
Post by Mike Jones
-----Original Message----- From: Anthony Nadalin Sent: Wednesday,
February 1, 2017 4:27 PM To: Stephen Farrell
[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
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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
Wednesday, February 1, 2017 4:10 PM To: Stephen Farrell
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
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
positions.
The document, along with other ballot positions, can be
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
---------------------------------------------------------------------
-
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Mike Jones
2017-03-06 22:34:03 UTC
Permalink
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:***@cs.tcd.ie]
Sent: Monday, March 6, 2017 2:10 PM
To: Mike Jones <***@microsoft.com>; Anthony Nadalin <***@microsoft.com>; joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@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/
Post by Mike Jones
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.
Post by Mike Jones
Thanks, -- Mike
-----Original Message----- From: Mike Jones
[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
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
Best wishes, -- Mike
-----Original Message----- From: Stephen Farrell
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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
Post by Mike Jones
-----Original Message----- From: Anthony Nadalin Sent: Wednesday,
February 1, 2017 4:27 PM To: Stephen Farrell
[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
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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
Wednesday, February 1, 2017 4:10 PM To: Stephen Farrell
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
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
positions.
The document, along with other ballot positions, can be found
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
----------------------------------------------------------------
-----
-
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Stephen Farrell
2017-03-06 22:38:53 UTC
Permalink
Hi Mike,
Post by Mike Jones
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.
Post by Mike Jones
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
[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/
Post by Mike Jones
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.
"
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.
Post by Mike Jones
Thanks, -- Mike
-----Original Message----- From: Mike Jones
6:17 PM To: Stephen Farrell
Anthony
[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
4:45 PM To: Mike Jones
Anthony Nadalin
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
Best wishes, -- Mike
-----Original Message----- From: Stephen Farrell
2017 4:31 PM To: Mike Jones
Anthony
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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
Post by Mike Jones
Wednesday,
February 1, 2017 4:27 PM To: Stephen Farrell
[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
2017 4:24 PM To: Mike Jones
Anthony
Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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
Wednesday, February 1, 2017 4:10 PM To: Stephen Farrell
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
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
2017 2:26 PM To: Mike Jones
joel
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Farrell
Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
[OAUTH-WG] Stephen Farrell's Discuss
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
positions.
The document, along with other ballot positions, can be
found
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
----------------------------------------------------------------
-----
-
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Mike Jones
2017-03-07 17:17:20 UTC
Permalink
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:***@cs.tcd.ie]
Sent: Monday, March 6, 2017 2:39 PM
To: Mike Jones <***@microsoft.com>; Anthony Nadalin <***@microsoft.com>; joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)


Hi Mike,
Post by Mike Jones
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.
Post by Mike Jones
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
[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/
Post by Mike Jones
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.
"
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.
Post by Mike Jones
Thanks, -- Mike
-----Original Message----- From: Mike Jones
6:17 PM To: Stephen Farrell
Anthony
[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
4:45 PM To: Mike Jones
Anthony Nadalin
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
Best wishes, -- Mike
-----Original Message----- From: Stephen Farrell
2017 4:31 PM To: Mike Jones
Anthony
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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
Post by Mike Jones
Wednesday,
February 1, 2017 4:27 PM To: Stephen Farrell
[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
2017 4:24 PM To: Mike Jones
Anthony
Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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
Wednesday, February 1, 2017 4:10 PM To: Stephen Farrell
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-recognitio
n
-report-evaluates-needle-haystack-search-capability.html
-----Original Message----- From: Stephen Farrell
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
2017 2:26 PM To: Mike Jones
joel
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Farrell
Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
[OAUTH-WG] Stephen Farrell's Discuss
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
positions.
The document, along with other ballot positions, can be
found
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
----------------------------------------------------------------
-----
-
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Stephen Farrell
2017-03-07 18:10:38 UTC
Permalink
Post by Mike Jones
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.
Ah good, that explains the disconnect.

Cheers,
S.
Post by Mike Jones
-- Mike
-----Original Message----- From: Stephen Farrell
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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.
Post by Mike Jones
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
[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/
Post by Mike Jones
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.
"
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.
Post by Mike Jones
Thanks, -- Mike
-----Original Message----- From: Mike Jones
6:17 PM To: Stephen Farrell
Anthony
[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
4:45 PM To: Mike Jones
Anthony Nadalin
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
Best wishes, -- Mike
-----Original Message----- From: Stephen Farrell
2017 4:31 PM To: Mike Jones
Anthony
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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
Post by Mike Jones
Wednesday,
February 1, 2017 4:27 PM To: Stephen Farrell
Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
[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
2017 4:24 PM To: Mike Jones
Anthony
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Nadalin
Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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
Wednesday, February 1, 2017 4:10 PM To: Stephen Farrell
Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
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-recognitio
n
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
-report-evaluates-needle-haystack-search-capability.html
-----Original Message----- From: Stephen Farrell
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
February 1,
2017 2:26 PM To: Mike Jones
joel
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Farrell
Sent: Wednesday, February 1, 2017 7:03 AM To: joel
jaeggli
[OAUTH-WG] Stephen Farrell's Discuss
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
positions.
The document, along with other ballot positions, can
be found
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
----------------------------------------------------------------
-----
Post by Mike Jones
Post by Mike Jones
-
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Mike Jones
2017-03-09 05:53:15 UTC
Permalink
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:***@cs.tcd.ie]
Sent: Tuesday, March 7, 2017 10:11 AM
To: Mike Jones <***@microsoft.com>; Anthony Nadalin <***@microsoft.com>; joel jaeggli <***@bogus.com>; The IESG <***@ietf.org>
Cc: oauth-***@ietf.org; draft-ietf-oauth-amr-***@ietf.org; ***@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Ah good, that explains the disconnect.

Cheers,
S.
Post by Mike Jones
-- Mike
-----Original Message----- From: Stephen Farrell
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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.
Post by Mike Jones
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
[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/
Post by Mike Jones
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.
"
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.
Post by Mike Jones
Thanks, -- Mike
-----Original Message----- From: Mike Jones
6:17 PM To: Stephen Farrell
Anthony
u
[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
4:45 PM To: Mike Jones
Anthony Nadalin
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
u
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
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.
Post by Mike Jones
Best wishes, -- Mike
-----Original Message----- From: Stephen Farrell
2017 4:31 PM To: Mike Jones
Anthony
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
l
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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
Post by Mike Jones
Wednesday,
February 1, 2017 4:27 PM To: Stephen Farrell
Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
a
[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
2017 4:24 PM To: Mike Jones
Anthony
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Nadalin
a
Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by Mike Jones
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.
Post by Mike Jones
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
Wednesday, February 1, 2017 4:10 PM To: Stephen Farrell
Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
;
v
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-recogniti
o
n
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
-report-evaluates-needle-haystack-search-capability.html
-----Original Message----- From: Stephen Farrell
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
2017 2:26 PM To: Mike Jones
;
joel
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
v
[OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Post by Mike Jones
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?
Post by Mike Jones
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?
Post by Mike Jones
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.
Post by Mike Jones
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
Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
[OAUTH-WG] Stephen Farrell's Discuss
on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Post by joel jaeggli
Post by Stephen Farrell
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
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
positions.
The document, along with other ballot positions, can be found
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
---------------------------------------------------------------------
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
-
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
--------------------------------------------------------------
--
-----
Post by Mike Jones
Post by Mike Jones
-
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by Mike Jones
Post by joel jaeggli
Post by Stephen Farrell
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.
Manger, James
2017-02-02 03:33:31 UTC
Permalink
Post by Mike Jones
You can call me lazy if you want. Some of them are so well known, such as "password" or "PIN" it didn't seem worthwhile to try to track down a reference.
"password" and "PIN" are so well known, yet curiously they are quite different as "amr" values.
"pwd" is merely defined as "password-based authentication".
But "pin" is not just a short numeric password. The "pin" amr value means authentication uses a (probably device-specific) crypto key that was unlocked with a local PIN or pattern and has defences against repeated guesses.

As a relying party, seeing "pin" means if it is an attacker they needed the user's device and to know their PIN (within a couple of guesses), and there shouldn't be much systemic risk from server-side password DB breaches.
Seeing "pwd" means if it is an attacker they needed to guess the user's password or get it from a password breach. Whether it is was a user-chosen password with zero restrictions and susceptible to dictionary attack, or a 12-char upper+lower+numeric+symbol not-in-common-list changed-monthly not-in-last-20 password, you don't know.


As to the "Specification Document(s)" column in the registry, it would better to leave it blank for those values where the spec provides nothing beyond the Name and Description that are in the registry anyway (such as "iris", "fpt", "geo", iris", "pwd", "retina", "sc", "sms", "tel", "user", "vbm").
In some other cases the only thing in the spec, but not the registry, is a reference to another spec so wouldn't it be better to put that reference in the registry directly. For instance, { kba; Knowledge-based authentication; [NIST.800-63-2] [ISO29115]}. Similarly for "hwk", "rba", "otp", "swk", "wia".


--
James Manger
Continue reading on narkive:
Loading...