Name and definition of "backchannel_user_code_parameter" client metadata parameter

[Justin Richer]

From my review of CIBA as IANA designated expert:

‌

Section 16.2 defines “backchannel_user_code_parameter”, with the description text of:

Indicates whether the Client must support the CIBA user_code parameter.

However, section 4, referenced from the registration, defines it as:

Boolean value specifying whether the Client supports the user_code parameter.

The discrepancy is that the text in 16 is a requirement (must support) with expectations that an AS could ostensibly count on (as in, the client will always use that parameter), whereas the text in 4 is a statement of capability (as in the client could use that parameter when it wants to).

This is likely a small change, but I’m not sure which direction the WG intends, so hopefully Mike can clarify. I personally think the language in 4 I likely the intended direction, so removing the “must” and fixing the grammar:

Indicates whether the Client supports the CIBA user_code parameter.

I don’t want to get into bike shedding, but I do think this is a good a time as any to point out that “backchannel_user_code_parameter” isn’t a great name for this field. As it stands, it sounds like it’s declaring the name of the parameter that will contain the user code, not a flag to turn a function on/off. It should probably be “backchannel_user_code_parameter_supported” or “backchannel_user_code_parameter_required”, to parallel other parameters in the registry from other specifications.

[Brian Campbell]

As far as I understand it, it’s meant to indicate something that the AS could ostensibly count on. But only to count on the ability to use the parameter (to send the `missing_user_code` error, for example, and have the client resend) not to require the client always send the parameter. Section 7.2 has more on the user code in general including the text, “The Client registration parameter backchannel_user_code_parameter specifies if support for user code is required from the Client." Both of the musts are about being able to support use of the user code parameter rather than required use of the parameter on each runtime protocol interaction.

I’ll readily admit much of this text is rather clumsy. But viewed in this light, I don’t think there is actually a discrepancy. If a change were to be made though, I’d concur with your intended direction and think removing both “must”'s (and fixing grammar) would still convey the intention.

CIBA core is final, however, so changes at this point would need to be errata.

FWIW I agree with the sentiments you’ve expressed in bike shedding but changing parameter names at this point isn’t really a viable option.

‌

‌

[Justin Richer]

An errata to align the definition text would be fine, and I would consider the issue addressed with that approach.

[Bjorn Hjelm]

The working group discussed this on Jan. 31 and there was a general agreement for the proposed text to be included in an errata.

[Brian Campbell]

Related to IANA and errata and #206 - from https://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20221205/001885.html

Furthermore, on looking at it again as a result of this, the OAuth Parameters registration request doesn't look right to me. I don't know what happened there. Maybe Dave knows and can tell me why I'm wrong here? But unless I'm somehow confused, it should indicate "token request" rather than "token response" for the "Parameter usage location:" and refer to Section 10.1 rather than 7.3. I believe that'd be errata qualifying change too, which is good. But unfortunately would mean publishing a CIBA errata.

‌