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

[Stephen Farrell <[e-mail]>]

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

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

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

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

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

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

Cheers,
S.


> 
> Best wishes, -- Mike
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[e-mail]] Sent: Wednesday, February 1, 2017
> 4:31 PM To: Mike Jones <[e-mail]>; Anthony Nadalin
> <[e-mail]>; joel jaeggli <[e-mail]>; The IESG
> <[e-mail]> Cc: [e-mail];
> [e-mail]; [e-mail] Subject: Re:
> [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
> 
> 
> 
> On 02/02/17 00:28, Mike Jones wrote:
>> The other case of known interop testing of "amr" values is for
>> MODRNA (OpenID Connect Mobile Profile) implementations.  There's a
>> reference to its use of "amr" values in the spec.
> 
> Yeah, iirc, that one seemed ok (assuming the reference tells me what
> code to write which I assume it does).
> 
> I'm still not seeing why some do have sufficient references and
> others do not.
> 
> Is there some difficulty with finding references or something?
> 
> S
> 
>> 
>> -----Original Message----- From: Anthony Nadalin Sent: Wednesday, 
>> February 1, 2017 4:27 PM To: Stephen Farrell 
>> <[e-mail]>; Mike Jones 
>> <[e-mail]>; joel jaeggli <[e-mail]>;
>> The IESG <[e-mail]> Cc: [e-mail]; 
>> [e-mail]; [e-mail] 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:[e-mail]] Sent: Wednesday, February 1,
>> 2017 4:24 PM To: Mike Jones <[e-mail]>; Anthony
>> Nadalin <[e-mail]>; joel jaeggli <[e-mail]>;
>> The IESG <[e-mail]> Cc: [e-mail]; 
>> [e-mail]; [e-mail] Subject: Re: 
>> [OAUTH-WG] Stephen Farrell's Discuss on 
>> draft-ietf-oauth-amr-values-05: (with DISCUSS)
>> 
>> 
>> 
>> On 02/02/17 00:21, Mike Jones wrote:
>>> Thanks, Tony.  I can add that reference.
>>> 
>>> Stephen, the sets of initial values were chosen from those used
>>> in practice by Microsoft and Google in real deployments.
>> 
>> Genuine questions: do you aim to have interop between those 
>> deployments? What if I wanted to write code that'd interop with
>> msft or google?
>> 
>> S.
>> 
>>> 
>>> About "otp", there are existing use cases for indicating that an 
>>> OTP was used.  I'm not aware of any of these use cases where the
>>>  distinction between TOTP and HOTP is important.  Thus, having 
>>> "otp" now makes sense, where having "hotp" and "totp" now
>>> doesn't.
>>> 
>>> Stephen, this may seem like splitting hairs, but the registry 
>>> instructions for "Specification Document(s)" are about having a 
>>> reference for the document where the Authentication Method 
>>> Reference Name (such as "otp") is defined.  In all cases for the 
>>> initial values, this is the RFC-to-be, so the registry
>>> instructions are satisfied.  If someone were, for instance, to
>>> define the string "hotp", it would be incumbent on the person
>>> requesting its registration to provide a URL to the document
>>> where the string "hotp" is defined.  Also having a reference to
>>> RFC 4226 in that document would be a good thing, but that isn't
>>> what the registry instructions are about.
>>> 
>>> All that said, I can look at also finding appropriate references 
>>> for the remaining values that don't currently have them.
>>> (Anyone got a good reference for password or PIN to suggest, for 
>>> instance?)
>>> 
>>> -- Mike
>>> 
>>> -----Original Message----- From: Anthony Nadalin Sent: Wednesday,
>>>  February 1, 2017 4:10 PM To: Stephen Farrell 
>>> <[e-mail]>; Mike Jones 
>>> <[e-mail]>; joel jaeggli <[e-mail]>; 
>>> The IESG <[e-mail]> Cc: [e-mail]; 
>>> [e-mail]; [e-mail] 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:[e-mail]] Sent: Wednesday, February 1, 
>>> 2017 2:26 PM To: Mike Jones <[e-mail]>; joel 
>>> jaeggli <[e-mail]>; The IESG <[e-mail]> Cc: 
>>> [e-mail]; [e-mail]; 
>>> [e-mail] Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss 
>>> on draft-ietf-oauth-amr-values-05: (with DISCUSS)
>>> 
>>> 
>>> Hi Mike,
>>> 
>>> On 01/02/17 17:00, Mike Jones wrote:
>>>> Thanks for the discussion, Stephen.
>>>> 
>>>> To your point about "otp", the working group discussed this
>>>> very point.  They explicitly decided not to introduce "hotp"
>>>> and "totp" identifiers because no one had a use case in which
>>>> the distinction mattered.
>>> 
>>> Then I'm not following why adding "otp" to the registry now is a 
>>> good plan.
>>> 
>>> If there's a use-case now, then adding an entry with a good 
>>> reference to the relevant spec seems right.
>>> 
>>> If there's no use-case now, then not adding it to the registry 
>>> seems right. (Mentioning it as a possible future entry would be 
>>> fine.)
>>> 
>>> I think the same logic would apply for all the values that this 
>>> spec adds to the registry. Why is that wrong?
>>> 
>>>> Others can certainly introduce those identifiers and register 
>>>> them if they do have such a use case, once the registry has
>>>> been established.  But the working group wanted to be
>>>> conservative about the identifiers introduced to prime the
>>>> registry, and this is such a case.
>>>> 
>>>> What identifiers to use and register will always be a balancing
>>>>  act. You want to be as specific as necessary to add practical 
>>>> and usable value, but not so specific as to make things 
>>>> unnecessarily brittle.
>>> 
>>> Eh... don't we want interop? Isn't that the primary goal here?
>>> 
>>>> While some might say there's a difference between serial number
>>>>  ranges of particular authentication devices, going there is 
>>>> clearly in the weeds.  On the other hand, while there used to
>>>> be an "eye" identifier, Elaine Newton of NIST pointed out that
>>>> there are significant differences between retina and iris
>>>> matching, so "eye" was replaced with "retina" and "iris".
>>>> Common sense informed by actual data is the key here.
>>> 
>>> That's another good example. There's no reference for "iris." If 
>>> that is used in some protocol, then what format(s) are expected
>>> to be supported? Where do I find that spec? If we can answer
>>> that, then great, let's add the details. If not, then I'd suggest
>>> we omit "iris" and leave it 'till later to add an entry for that.
>>> And again, including text with "iris" as an example is just fine,
>>> all I'm asking is that we only add the registry entry if we can
>>> meet the same bar that we're asking the DE to impose on later 
>>> additions.
>>> 
>>> And the same for all the others...
>>> 
>>> Cheers, S.
>>> 
>>> 
>>>> 
>>>> The point of the registry requiring a specification reference
>>>> is so people using the registry can tell where the identifier
>>>> is defined. For all the initial values, that requirement is 
>>>> satisfied, since the reference will be to the new RFC.  I
>>>> think that aligns with the point that Joel was making.
>>>> 
>>>> Your thoughts?
>>>> 
>>>> -- Mike
>>>> 
>>>> -----Original Message----- From: OAuth 
>>>> [mailto:[e-mail]] On Behalf Of Stephen Farrell 
>>>> Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli 
>>>> <[e-mail]>; The IESG <[e-mail]> Cc: 
>>>> [e-mail]; [e-mail]; 
>>>> [e-mail] Subject: Re: [OAUTH-WG] Stephen Farrell's
>>>> Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
>>>> 
>>>> 
>>>> 
>>>> On 01/02/17 14:58, joel jaeggli wrote:
>>>>> On 1/31/17 8:26 AM, Stephen Farrell wrote:
>>>>>> Stephen Farrell has entered the following ballot position
>>>>>> for draft-ietf-oauth-amr-values-05: Discuss
>>>>>> 
>>>>>> When responding, please keep the subject line intact and 
>>>>>> reply to all email addresses included in the To and CC
>>>>>> lines. (Feel free to cut this introductory paragraph,
>>>>>> however.)
>>>>>> 
>>>>>> 
>>>>>> Please refer to 
>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>>> for more information about IESG DISCUSS and COMMENT
>>>>>> positions.
>>>>>> 
>>>>>> 
>>>>>> The document, along with other ballot positions, can be
>>>>>> found here: 
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>
>>>>>> 
---------------------------------------------------------------------
>>>>>> 
>>>>>> 
>>> 
>>>>>> 
>> -
>>>>>> DISCUSS: 
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>>
>>>
>>>>>>
>>
>>>>>>
>
>>>>>> 
-
>>>>>> 
>>>>>> This specification seems to me to break it's own rules. You
>>>>>>  state that registrations should include a reference to a 
>>>>>> specification to improve interop. And yet, for the strings
>>>>>>  added here (e.g. otp) you don't do that (referring to
>>>>>> section 2 will not improve interop) and there are different
>>>>>> ways in which many of the methods in section 2 can be done.
>>>>>> So I think you need to add a bunch more references.
>>>>> 
>>>>> Not clear to me that the document creating the registry
>>>>> needs to adhere to the rules for further allocations in order
>>>>> to prepoulate the registry. that is perhaps an appeal to
>>>>> future consistency.
>>>> 
>>>> Sure - I'm all for a smattering of inconsistency:-)
>>>> 
>>>> But I think the lack of specs in some of these cases could 
>>>> impact on interop, e.g. in the otp case, they quote two RFCs
>>>> and yet only have one value. That seems a bit broken to me, so
>>>> the discuss isn't really about the formalism.
>>>> 
>>>> S.
>>>> 
>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>