[Openid-specs-mobile-profile] Issue #211: Name and definition of "backchannel_user_code_parameter" client metadata parameter (openid/mobile)

[Justin Richer]

New issue 211: Name and definition of "backchannel_user_code_parameter" client metadata parameter
https://bitbucket.org/openid/mobile/issues/211/name-and-definition-of

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.