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: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. >> >> >>>> >>>> >>>> >>> >>> >> >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth