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