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:stephen.farr...@cs.tcd.ie]
Sent: Wednesday, February 1, 2017 4:31 PM
To: Mike Jones <michael.jo...@microsoft.com>; Anthony Nadalin
<tony...@microsoft.com>; joel jaeggli <joe...@bogus.com>; The IESG
<i...@ietf.org>
Cc: oauth-cha...@ietf.org; draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org
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
> <stephen.farr...@cs.tcd.ie>; Mike Jones
> <michael.jo...@microsoft.com>; joel jaeggli <joe...@bogus.com>; The
> IESG <i...@ietf.org> Cc: oauth-cha...@ietf.org;
> draft-ietf-oauth-amr-val...@ietf.org; oauth@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:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1, 2017
> 4:24 PM To: Mike Jones <michael.jo...@microsoft.com>; Anthony Nadalin
> <tony...@microsoft.com>; joel jaeggli <joe...@bogus.com>; The IESG
> <i...@ietf.org> Cc: oauth-cha...@ietf.org;
> draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org 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
>> <stephen.farr...@cs.tcd.ie>; Mike Jones
>> <michael.jo...@microsoft.com>; joel jaeggli <joe...@bogus.com>;
>> The IESG <i...@ietf.org> Cc: oauth-cha...@ietf.org;
>> draft-ietf-oauth-amr-val...@ietf.org; oauth@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:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1,
>> 2017 2:26 PM To: Mike Jones <michael.jo...@microsoft.com>; joel
>> jaeggli <joe...@bogus.com>; The IESG <i...@ietf.org> Cc:
>> oauth-cha...@ietf.org; draft-ietf-oauth-amr-val...@ietf.org;
>> oauth@ietf.org 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:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell
>>> Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
>>> <joe...@bogus.com>; The IESG <i...@ietf.org> Cc:
>>> oauth-cha...@ietf.org; draft-ietf-oauth-amr-val...@ietf.org;
>>> oauth@ietf.org 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.
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
