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.
-- 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-valu
>> 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-valu
>> 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-val
>>> 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-va
>>>> 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-va
>>>> 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-recognitio
>>>>> 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
