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

From: joel jaeggli <[email-masked]>
Date: Wed, 1 Feb 2017 06:58:54 -0800

On 1/31/17 8:26 AM, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-oauth-amr-values-05: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This specification seems to me to break it's own
> rules. You state that registrations should include
> a reference to a specification to improve interop.
> And yet, for the strings added here (e.g. otp) you
> don't do that (referring to section 2 will not
> improve interop) and there are different ways in
> which many of the methods in section 2 can be done.
> So I think you need to add a bunch more references.

Not clear to me that the document creating the registry needs to adhere
to the rules for further allocations in order to prepoulate the
registry. that is perhaps an appeal to future consistency.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 Feb 2017 15:02:56 +0000

> registry. that is perhaps an appeal to future consistency.

Sure - I'm all for a smattering of inconsistency:-)

But I think the lack of specs in some of these cases
could impact on interop, e.g. in the otp case, they
quote two RFCs and yet only have one value. That seems
a bit broken to me, so the discuss isn't really about
the formalism.

S.

---

From: Mike Jones <[email-masked]>
Date: Wed, 1 Feb 2017 17:00:47 +0000

Thanks for the discussion, Stephen.

To your point about "otp", the working group discussed this very point.  They explicitly decided not to introduce "hotp" and "totp" identifiers because no one had a use case in which the distinction mattered.  Others can certainly introduce those identifiers and register them if they do have such a use case, once the registry has been established.  But the working group wanted to be conservative about the identifiers introduced to prime the registry, and this is such a case.

What identifiers to use and register will always be a balancing act.  You want to be as specific as necessary to add practical and usable value, but not so specific as to make things unnecessarily brittle.  While some might say there's a difference between serial number ranges of particular authentication devices, going there is clearly in the weeds.  On the other hand, while there used to be an "eye" identifier, Elaine Newton of NIST pointed out that there are significant differences between retina and iris matching, so "eye" was replaced with "retina" and "iris".  Common sense informed by actual data is the key here.

The point of the registry requiring a specification reference is so people using the registry can tell where the identifier is defined.  For all the initial values, that requirement is satisfied, since the reference will be to the new RFC.  I think that aligns with the point that Joel was making.

Your thoughts?

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Wednesday, February 1, 2017 7:03 AM
To: joel jaeggli <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

On 01/02/17 14:58, joel jaeggli wrote:
>> 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
>> 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.
> Not clear to me that the document creating the registry needs to 
> adhere to the rules for further allocations in order to prepoulate the 

But I think the lack of specs in some of these cases could impact on interop, e.g. in the otp case, they quote two RFCs and yet only have one value. That seems a bit broken to me, so the discuss isn't really about the formalism.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 Feb 2017 22:25:47 +0000

Hi Mike,

On 01/02/17 17:00, Mike Jones wrote:
> To your point about "otp", the working group discussed this very
> point.  They explicitly decided not to introduce "hotp" and "totp"
> identifiers because no one had a use case in which the distinction
> mattered.  

Then I'm not following why adding "otp" to the registry now
is a good plan.

If there's a use-case now, then adding an entry with a good
reference to the relevant spec seems right.

If there's no use-case now, then not adding it to the
registry seems right. (Mentioning it as a possible future
entry would be fine.)

I think the same logic would apply for all the values that
this spec adds to the registry. Why is that wrong?

> Others can certainly introduce those identifiers and
> register them if they do have such a use case, once the registry has
> been established.  But the working group wanted to be conservative
> about the identifiers introduced to prime the registry, and this is
> such a case.
> 
> What identifiers to use and register will always be a balancing act.
> You want to be as specific as necessary to add practical and usable
> value, but not so specific as to make things unnecessarily brittle.

Eh... don't we want interop? Isn't that the primary goal here?

> While some might say there's a difference between serial number
> ranges of particular authentication devices, going there is clearly
> in the weeds.  On the other hand, while there used to be an "eye"
> identifier, Elaine Newton of NIST pointed out that there are
> significant differences between retina and iris matching, so "eye"
> was replaced with "retina" and "iris".  Common sense informed by
> actual data is the key here.

That's another good example. There's no reference for "iris." If
that is used in some protocol, then what format(s) are expected
to be supported? Where do I find that spec? If we can answer that,
then great, let's add the details. If not, then I'd suggest we
omit "iris" and leave it 'till later to add an entry for that.
And again, including text with "iris" as an example is just fine,
all I'm asking is that we only add the registry entry if we can
meet the same bar that we're asking the DE to impose on later
additions.

And the same for all the others...

Cheers,
S.

> 
> The point of the registry requiring a specification reference is so
> people using the registry can tell where the identifier is defined.
> For all the initial values, that requirement is satisfied, since the
> reference will be to the new RFC.  I think that aligns with the point
> that Joel was making.
> 
> Your thoughts?
> 
> -- Mike
> 
> -----Original Message----- From: OAuth
> [mailto:[email-masked]] On Behalf Of Stephen Farrell Sent:
> Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
> <[email-masked]>; The IESG <[email-masked]> Cc:
> [email-masked]; [email-masked];
> [email-masked] Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
> 
> 
> 
>>> 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.
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>>
>>> 
-
>>> DISCUSS: 
>>> ---------------------------------------------------------------------
>>>
>>> 
-
>>>  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.
>> 
>> adhere to the rules for further allocations in order to prepoulate
>> the registry. that is perhaps an appeal to future consistency.
> 
> But I think the lack of specs in some of these cases could impact on
> interop, e.g. in the otp case, they quote two RFCs and yet only have
> one value. That seems a bit broken to me, so the discuss isn't really
> about the formalism.
> 
> S.
> 
> 
>>> 
>>> 
>>> 
>> 
>> 
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 2 Feb 2017 00:10:22 +0000

NIST asked for the addition of IRIS (as they are seeing more use of IRIS over retina due to the accuracy of iris)  as they have been doing significant testing on various iris devices and continue to do so, here is a report that NIST released http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-report-evaluates-needle-haystack-search-capability.html  

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

Hi Mike,

Cheers,
S.

-
-

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Feb 2017 00:14:56 +0000

Hi Tony,

On 02/02/17 00:10, Anthony Nadalin wrote:
> NIST asked for the addition of IRIS (as they are seeing more use of
> IRIS over retina due to the accuracy of iris)  as they have been
> doing significant testing on various iris devices and continue to do
> so, here is a report that NIST released
> 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.

> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Wednesday, February 1, 2017
> 2:26 PM To: Mike Jones <[email-masked]>; joel jaeggli
> Then I'm not following why adding "otp" to the registry now is a good
> plan.
> 
> If there's a use-case now, then adding an entry with a good reference
> to the relevant spec seems right.
> 
> If there's no use-case now, then not adding it to the registry seems
> right. (Mentioning it as a possible future entry would be fine.)
> 
> I think the same logic would apply for all the values that this spec
> adds to the registry. Why is that wrong?
> 
>> Others can certainly introduce those identifiers and register them
>> if they do have such a use case, once the registry has been
>> established.  But the working group wanted to be conservative about
>> the identifiers introduced to prime the registry, and this is such
>> a case.
>> 
>> What identifiers to use and register will always be a balancing
>> act. You want to be as specific as necessary to add practical and
>> usable value, but not so specific as to make things unnecessarily
>> brittle.
> 
>> 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 
> 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.
> 
> Cheers, S.
>> The point of the registry requiring a specification reference is
>> so people using the registry can tell where the identifier is
>> defined. For all the initial values, that requirement is satisfied,
>> since the reference will be to the new RFC.  I think that aligns
>> with the point that Joel was making.
>> 
>> Your thoughts?
>> 
>> -- Mike
>> 
>> [email-masked] Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss
>> on draft-ietf-oauth-amr-values-05: (with 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 
-
-
>>>> 
>>>> 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.
>>> 
>>>  adhere to the rules for further allocations in order to
>>> prepoulate the registry. that is perhaps an appeal to future
>>> consistency.
>> 
>> But I think the lack of specs in some of these cases could impact
>> on interop, e.g. in the otp case, they quote two RFCs and yet only
>> have one value. That seems a bit broken to me, so the discuss isn't
>> really about the formalism.
>> 
>> S.
>> 
>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 2 Feb 2017 00:21:42 +0000

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

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

Hi Tony,

Am I missing something?

Cheers,
S.

-
-

---

From: Mike Jones <[email-masked]>
Date: Thu, 2 Feb 2017 00:21:45 +0000

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: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, February 1, 2017 2:26 PM
To: Mike Jones <[email-masked]>; joel jaeggli <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

Hi Mike,

Cheers,
S.

-
-

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Feb 2017 00:24:05 +0000

On 02/02/17 00:21, Mike Jones wrote:
> Stephen, the sets of initial values were chosen from those used in
> practice by Microsoft and Google in real deployments.

Genuine questions: do you aim to have interop between those
deployments? What if I wanted to write code that'd interop
with msft or google?

S.

> 
> About "otp", there are existing use cases for indicating that an OTP
> was used.  I'm not aware of any of these use cases where the
> distinction between TOTP and HOTP is important.  Thus, having "otp"
> now makes sense, where having "hotp" and "totp" now doesn't.
> 
> Stephen, this may seem like splitting hairs, but the registry
> instructions for "Specification Document(s)" are about having a
> reference for the document where the Authentication Method Reference
> Name (such as "otp") is defined.  In all cases for the initial
> values, this is the RFC-to-be, so the registry instructions are
> satisfied.  If someone were, for instance, to define the string
> "hotp", it would be incumbent on the person requesting its
> registration to provide a URL to the document where the string "hotp"
> is defined.  Also having a reference to RFC 4226 in that document
> would be a good thing, but that isn't what the registry instructions
> are about.
> 
> All that said, I can look at also finding appropriate references for
> the remaining values that don't currently have them.  (Anyone got a
> good reference for password or PIN to suggest, for instance?)
> 
> -- Mike
> 
> -----Original Message----- From: Anthony Nadalin Sent: Wednesday,
> February 1, 2017 4:10 PM To: Stephen Farrell
> <[email-masked]>; Mike Jones
> <[email-masked]>; joel jaeggli <[email-masked]>; The
> IESG <[email-masked]> Cc: [email-masked];
> [email-masked]; [email-masked] Subject: RE:
> [OAUTH-WG] Stephen Farrell's Discuss on
-
-

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 2 Feb 2017 00:27:12 +0000

We have interoped between FIDO authenticators vendors and Windows Hello

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

S.

-
-

---

From: Mike Jones <[email-masked]>
Date: Thu, 2 Feb 2017 00:28:49 +0000

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: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, February 1, 2017 4:24 PM
To: Mike Jones <[email-masked]>; Anthony Nadalin <[email-masked]>; joel jaeggli <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

S.

-
-

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Feb 2017 00:31:14 +0000

On 02/02/17 00:28, Mike Jones wrote:
> The other case of known interop testing of "amr" values is for MODRNA
> (OpenID Connect Mobile Profile) implementations.  There's a reference
> to its use of "amr" values in the spec.

Yeah, iirc, that one seemed ok (assuming the reference tells
me what code to write which I assume it does).

I'm still not seeing why some do have sufficient references
and others do not.

Is there some difficulty with finding references or something?

S

> February 1, 2017 4:27 PM To: Stephen Farrell
> 4:24 PM To: Mike Jones <[email-masked]>; Anthony Nadalin
> <[email-masked]>; joel jaeggli <[email-masked]>; The IESG
> <[email-masked]> Cc: [email-masked];
> [email-masked]; [email-masked] Subject: Re:
> deployments? What if I wanted to write code that'd interop with msft
> or google?
> 
> S.
> 
>> 
>> About "otp", there are existing use cases for indicating that an
>> OTP was used.  I'm not aware of any of these use cases where the 
>> distinction between TOTP and HOTP is important.  Thus, having
>> "otp" now makes sense, where having "hotp" and "totp" now doesn't.
>> 
>> 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
>> 
>> <[email-masked]>; joel jaeggli <[email-masked]>;
>> The IESG <[email-masked]> Cc: [email-masked]; 
>> 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 
>> [mailto:[email-masked]] Sent: Wednesday, February 1,
>> 2017 2:26 PM To: Mike Jones <[email-masked]>; joel
>> jaeggli <[email-masked]>; The IESG <[email-masked]> Cc: 
>>>  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 no use-case now, then not adding it to the registry
>> seems right. (Mentioning it as a possible future entry would be
>> fine.)
>> 
>> I think the same logic would apply for all the values that this
>> spec adds to the registry. Why is that wrong?
>> 
>>> Others can certainly introduce those identifiers and register
>>> them if they do have such a use case, once the registry has been 
>>> established.  But the working group wanted to be conservative
>>> about the identifiers introduced to prime the registry, and this
>>> is such a case.
>>> 
>>> act. You want to be as specific as necessary to add practical
>>> and usable value, but not so specific as to make things
>>> unnecessarily brittle.
>> 
>>> clearly in the weeds.  On the other hand, while there used to be
>>> an "eye" identifier, Elaine Newton of NIST pointed out that there
>>> are significant differences between retina and iris matching, so
>>> "eye" was replaced with "retina" and "iris".  Common sense
>>> informed by actual data is the key here.
>> 
>> 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.
>> 
>>> 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
>>> 
>>> [mailto:[email-masked]] On Behalf Of Stephen Farrell
>>> Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli 
>>>>> 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 
-
>>>>> 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 
>>> But I think the lack of specs in some of these cases could
>>> impact on interop, e.g. in the otp case, they quote two RFCs and
>>> yet only have one value. That seems a bit broken to me, so the
>>> discuss isn't really about the formalism.
>>> 
>>> S.
>>> 
>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 2 Feb 2017 00:35:33 +0000

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:[email-masked]] 
Sent: Wednesday, February 1, 2017 4:31 PM
To: Mike Jones <[email-masked]>; Anthony Nadalin <[email-masked]>; joel jaeggli <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

S

-

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Feb 2017 00:45:01 +0000

On 02/02/17 00:35, Mike Jones wrote:
> You can call me lazy if you want. 

I don't think you're lazy:-) Were I to guess I'd guess that
interop for these wasn't a priority and that we're defining
them a bit early and a little too generically.

> Some of them are so well known,
> such as "password" or "PIN" it didn't seem worthwhile to try to track
> down a reference. 

Sure, those are fine. The only issues would be if there's
a string2key function somewhere but I don't expect there
is in this context.

> But I'm willing to work with others to find decent
> references for the rest of them, if you believe that would improve
> the quality of the specification.

I do think it would, esp for cases where there are known
different options (e.g. otp) or likely ill-defined or
proprietary formats. My guess is that some biometrics fit
that latter but I could be wrong. If they do, then one
runs into the problem of having to depend on magic numbers
in the encodings or similar to distinguish which is really
error prone and likely to lead to what our learned
transport chums are calling ossification;-)

Cheers,
S.

> Best wishes, -- Mike
> 4:31 PM To: Mike Jones <[email-masked]>; Anthony Nadalin
>> 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.
> 
>> 2017 4:24 PM To: Mike Jones <[email-masked]>; Anthony
>> Nadalin <[email-masked]>; joel jaeggli <[email-masked]>;
>>> Stephen, the sets of initial values were chosen from those used
>>> in practice by Microsoft and Google in real deployments.
>> 
>> deployments? What if I wanted to write code that'd interop with
>> msft or google?
>> 
>> S.
>> 
>>> 
>>> initial values, this is the RFC-to-be, so the registry
>>> instructions are satisfied.  If someone were, for instance, to
>>> define the string "hotp", it would be incumbent on the person
>>> requesting its registration to provide a URL to the document
>>> where the string "hotp" is defined.  Also having a reference to
>>> RFC 4226 in that document would be a good thing, but that isn't
>>> what the registry instructions are about.
>>> 
>>> for the remaining values that don't currently have them.
>>> (Anyone got a good reference for password or PIN to suggest, for 
>>> instance?)
>>> 
>>> -- Mike
>>> 
>>> been doing significant testing on various iris devices and
>>> continue to do so, here is a report that NIST released 
>>>> To your point about "otp", the working group discussed this
>>>> very point.  They explicitly decided not to introduce "hotp"
>>>> and "totp" identifiers because no one had a use case in which
>>>> the distinction mattered.
>>> 
>>>> them if they do have such a use case, once the registry has
>>>> been established.  But the working group wanted to be
>>>> conservative about the identifiers introduced to prime the
>>>> registry, and this is such a case.
>>>> 
>>>> 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.
>>> 
>>> 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.
>>>> 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
>>>> 
>>>> [email-masked] Subject: Re: [OAUTH-WG] Stephen Farrell's
>>>> Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
>>>> 
>>>> 
>>>> 
>>>>>> Stephen Farrell has entered the following ballot position
>>>>>> for draft-ietf-oauth-amr-values-05: Discuss
>>>>>> 
>>>>>> reply to all email addresses included in the To and CC
>>>>>> lines. (Feel free to cut this introductory paragraph,
>>>>>> however.)
>>>>>> 
>>>>>> 
>>>>>> Please refer to 
-
>>>>>>  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.
>>>>> 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.
>>>> 
>>>> impact on interop, e.g. in the otp case, they quote two RFCs
>>>> and yet only have one value. That seems a bit broken to me, so
>>>> the discuss isn't really about the formalism.
>>>> 
>>>> S.
>>>> 
>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>

---

From: "Manger, James" <[email-masked]>
Date: Thu, 2 Feb 2017 03:33:31 +0000

> 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

---

From: Mike Jones <[email-masked]>
Date: Wed, 1 Mar 2017 02:16:52 +0000

Hi Stephen,

Draft -06 https://tools.ietf.org/html/draft-ietf-oauth-amr-values-06 adds references for all of the defined "amr" values.  Thanks for taking the time to have a thoughtful discussion.

				-- Mike

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

Cheers,
S.

-