Hi Stephen,
I've added text to the introduction explaining that the values are intended to
provide identifiers for families of closely-related authentication methods,
based on our discussion of this topic. See the diffs at
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-amr-values-07. Hopefully
this clarifies things sufficiently to satisfy the intent of your DISCUSS,
Stephen. Let me know.
I also updated the MODRNA Authentication Profile reference.
Thanks again,
-- Mike
-----Original Message-----
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Sent: Tuesday, March 7, 2017 10:11 AM
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 07/03/17 17:17, Mike Jones wrote:
> You're right, Stephen. Re-reading the spec, it doesn't say that, and
> it should. Sometimes it takes someone giving a spec a fresh read to
> uncover things that the authors understood and intended but failed to
> be captured in the text. This is such a case - so thanks.
>
> I'll add this information, which is necessary to understand the
> intent, and then republish.
Ah good, that explains the disconnect.
Cheers,
S.
>
> -- Mike
>
> -----Original Message----- From: Stephen Farrell
> [mailto:stephen.farr...@cs.tcd.ie] Sent: Monday, March 6, 2017 2:39 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)
>
>
> Hi Mike,
>
> On 06/03/17 22:34, Mike Jones wrote:
>> Thanks for the reply, Stephen. I'll try to find better
>> interop-producing references where possible.
>>
>>
>> In some cases, however, the values are intentionally intended to
>> provide an identifier for a family of closely-related methods, such
>> as "otp", which covers both time-based and HMAC-based OTPs.
>
> Hmm. I don't recall text saying that in the draft, but it's possible
> that I missed it - can you point me at that?
>
> I do agree that if the semantics here were "some otp was used" then it
> would not be necessary to specify exactly which OTP scheme was used.
> But that wasn't how I read what this spec was doing. (Again, that
> could be me getting the wrong end of the stick.)
>
> S.
>
>
>> Many relying parties will be content to know that an OTP has been
>> used in addition to a password. The distinction between which kind
>> of OTP was used is not useful to them. Thus, there's a single
>> identifier that can be satisfied in two or more nearly equivalent
>> ways. I consider this to be a feature - not a bug.
>>
>>
>>
>> Similarly, there's a whole range of nuances between different
>> fingerprint matching algorithms. They differ in false positive and
>> false negative rates over different population samples and also
>> differ based on the kind and model of fingerprint sensor used.
>> Like the OTP case, many RPs will be content to know that a
>> fingerprint match mas made, without delving into and differentiating
>> based on every aspect of the implementation of fingerprint capture
>> and match. Those that want more precision than this can always define
>> new "amr" values. But "fpt" is fine as is for what I believe will be
>> the 90+% case.
>>
>>
>>
>> Ultimately, the RP is depending upon the Identity Provider to do
>> reasonable things. If it didn't trust the IdP to do so, it has no
>> business using it. The "amr" value lets the IdP signal to the RP
>> additional information about what it did, for the cases in which that
>> information is useful to the RP.
>>
>>
>>
>> Reducing this to the point of absurdity, the RP would almost never
>> care about the make, model, and serial number of the fingerprint
>> reader or OTP. Values could be defined to provide that granularity.
>> But making those fine-grained distinctions are not useful in
>> practice.
>>
>>
>>
>> Please consider the existing definitions in light of that reductio ad
>> absurdum. The existing values only make distinctions that are known
>> to be useful to RPs. Slicing things more finely than would be used
>> in practice actually hurts interop, rather than helping it, because
>> it would force all RPs to recognize that several or many different
>> values actually mean the same thing to them.
>>
>>
>>
>> -- Mike
>>
>>
>>
>> -----Original Message----- From: Stephen Farrell
>> [mailto:stephen.farr...@cs.tcd.ie] Sent: Monday, March 6, 2017 2:10
>> 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)
>>
>>
>>
>>
>>
>> Hi Mike,
>>
>>
>>
>> Apologies - I updated the discuss ballot text [1] on Feb 28 but
>> must've not sent it as an email or something. Anyway...
>>
>>
>>
>> [1]
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ballot/
>>
>>
>>
>>
>>
On 06/03/17 20:38, Mike Jones wrote:
>>
>>> Hi Stephen. The changes in draft -06 were intended to address your
>>
>>> DISCUSS points. Are you satisfied with these changes or are there
>>
>>> additional changes you want? I'm asking partly because it's a week
>>
>>> now until the submission cutoff and if additional changes are
>>> needed,
>>
>>> I'd like to make them this week.
>>
>>
>>
>> So I do think there's still work to be done, may as well copy the new
>> ballot text here:
>>
>>
>>
>> "
>>
>> I think we still have the problem that the values "defined" here
>> (e.g. "fpt") are under specified to a significant degree. RFC4949
>> does not tell anyone how to achieve interop with "fpt" (nor any of
>> the other cases where you refer to 4949 I think). There is therefore
>> no utility in "defining" "fpt" as it will not achieve interop and in
>> fact is more likely to cause confusion than interop.
>> If the solution of actually defining the meaning of things like "fpt"
>> is not achievable then perhaps it will be better to only define those
>> for which we can get interop ("pwd" and one or two
>> others) and leave the definition of the rest for later. (In saying
>> that I do recall that one of the authors said that there are
>> implementations that use some of these type-names, but the point of
>> RFCs is not to "bless"
>>
>> such things, but to achieve interop.)
>>
>> "
>>
>>
>>
>> Cheers,
>>
>> S.
>>
>>
>>
>>>
>>
>>> Thanks, -- Mike
>>
>>>
>>
>>> -----Original Message----- From: Mike Jones
>>
>>> [mailto:michael.jo...@microsoft.com] Sent: Tuesday, February 28,
>>> 2017
>>
>>> 6:17 PM To: Stephen Farrell
>>> <stephen.farr...@cs.tcd.ie<mailto:stephen.farr...@cs.tcd.ie>>;
>>> Anthony
>>
>>> Nadalin <tony...@microsoft.com<mailto:tony...@microsoft.com>>;
>>> joel jaeggli <joe...@bogus.com<mailto:joe...@bogus.com>>; The
>>
>>> IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc:
>>> oauth-cha...@ietf.org<mailto:oauth-cha...@ietf.org>;
>>
>>> draft-ietf-oauth-amr-val...@ietf.org<mailto:draft-ietf-oauth-amr-val
>>> u
>>>
>>>
e...@ietf.org>; oauth@ietf.org<mailto:oauth@ietf.org> Subject: RE:
>>
>>> [OAUTH-WG] Stephen Farrell's Discuss on
>>
>>> draft-ietf-oauth-amr-values-05: (with DISCUSS)
>>
>>>
>>
>>> 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:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1,
>>> 2017
>>
>>> 4:45 PM To: Mike Jones
>>> <michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>;
>>>
>>>
Anthony Nadalin
>>
>>> <tony...@microsoft.com<mailto:tony...@microsoft.com>>; joel jaeggli
>>> <joe...@bogus.com<mailto:joe...@bogus.com>>; The IESG
>>
>>> <i...@ietf.org<mailto:i...@ietf.org>> Cc:
>>> oauth-cha...@ietf.org<mailto:oauth-cha...@ietf.org>;
>>
>>> draft-ietf-oauth-amr-val...@ietf.org<mailto:draft-ietf-oauth-amr-val
>>> u
>>>
>>>
e...@ietf.org>; oauth@ietf.org<mailto: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: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:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1,
>>
>>>> 2017 4:31 PM To: Mike Jones
>>>> <michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>;
>>>>
>>>>
Anthony
>>
>>>> Nadalin <tony...@microsoft.com<mailto:tony...@microsoft.com>>;
>>>> joel jaeggli <joe...@bogus.com<mailto:joe...@bogus.com>>; The
>>
>>>> IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc:
>>>> oauth-cha...@ietf.org<mailto:oauth-cha...@ietf.org>;
>>
>>>> draft-ietf-oauth-amr-val...@ietf.org<mailto:draft-ietf-oauth-amr-va
>>>> l
>>>>
>>>>
u...@ietf.org>; oauth@ietf.org<mailto: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<mailto:stephen.farr...@cs.tcd.ie>>;
>>>>>
>>>>>
Mike Jones
>>
>>>>> <michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>;
>>>>>
>>>>>
joel jaeggli <joe...@bogus.com<mailto:joe...@bogus.com>>; The
>>
>>>>> IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc:
>>>>> oauth-cha...@ietf.org<mailto:oauth-cha...@ietf.org>;
>>
>>>>> draft-ietf-oauth-amr-val...@ietf.org<mailto:draft-ietf-oauth-amr-v
>>>>> a
>>>>>
>>>>>
l...@ietf.org>; oauth@ietf.org<mailto: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<mailto:michael.jo...@microsoft.com>>;
>>>>>
>>>>>
Anthony
>>
>>>>> Nadalin
>>>>> <tony...@microsoft.com<mailto:tony...@microsoft.com>>; joel
>>>>> jaeggli <joe...@bogus.com<mailto:joe...@bogus.com>>;
>>
>>>>> The IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc:
>>
>>>>> oauth-cha...@ietf.org<mailto:oauth-cha...@ietf.org>;
>>>>> draft-ietf-oauth-amr-val...@ietf.org<mailto:draft-ietf-oauth-amr-v
>>>>> a
>>>>>
>>>>>
l...@ietf.org>;
>>
>>>>> oauth@ietf.org<mailto: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<mailto:stephen.farr...@cs.tcd.ie>>;
>>>>>>
>>>>>>
Mike Jones
>>
>>>>>> <michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>
>>>>>> ;
>>>>>>
>>>>>>
joel jaeggli <joe...@bogus.com<mailto:joe...@bogus.com>>;
>>
>>>>>> The IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc:
>>>>>> oauth-cha...@ietf.org<mailto:oauth-cha...@ietf.org>;
>>
>>>>>> draft-ietf-oauth-amr-val...@ietf.org<mailto:draft-ietf-oauth-amr-
>>>>>> v
>>>>>>
>>>>>>
al...@ietf.org>; oauth@ietf.org<mailto: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-recogniti
>>>>>> o
>>>>>>
>>>>>>
n
>>
>>>>>> -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<mailto:michael.jo...@microsoft.com>>
>>>>>> ;
>>>>>>
>>>>>>
joel
>>
>>>>>> jaeggli <joe...@bogus.com<mailto:joe...@bogus.com>>; The IESG
>>>>>> <i...@ietf.org<mailto:i...@ietf.org>> Cc:
>>
>>>>>> oauth-cha...@ietf.org<mailto:oauth-cha...@ietf.org>;
>>>>>> draft-ietf-oauth-amr-val...@ietf.org<mailto:draft-ietf-oauth-amr-
>>>>>> v
>>>>>>
>>>>>>
al...@ietf.org>;
>>
>>>>>> oauth@ietf.org<mailto: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<mailto:joe...@bogus.com>>; The IESG
>>>>>>> <i...@ietf.org<mailto:i...@ietf.org>> Cc:
>>
>>>>>>> oauth-cha...@ietf.org<mailto:oauth-cha...@ietf.org>;
>>>>>>> draft-ietf-oauth-amr-val...@ietf.org<mailto:draft-ietf-oauth-amr
>>>>>>> -val...@ietf.org>;
>>
>>>>>>>
>>>>>>>
oauth@ietf.org<mailto: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
