binding_message uses possibly undefined "plain text" term

[Joseph Heenan]

The binding_message definition says:

Because the devices may have limited display abilities and the message is intending for visual inspection by the end-user, the binding_message value SHOULD be relatively short and use a limited set of plain text characters.

I'm not sure how "plain text characters" is defined in this context. https://tools.ietf.org/html/rfc7994 defines it to contain tabs, newlines, etc and any valid unicode code point, which I don't think was the intention.

I'm unclear whether the intention was to allow (say) the use of kanji.

I'm presuming the OP should probably reject the authentication request with an error if it can't display the given binding message, this should perhaps be explicitly mentioned.

[Dave Tonge]

So I think that with the binding message its quite hard to specify this in a completely interoperable way. Its quite ecosystem-specific. Hence why this requirement is only a SHOULD. I think that "limited set" gets across the idea that its not every plain text character?

I can see an argument for defining a specific error for if the binding message received couldn't be displayed by the OP. However I think we can add this to the next version, rather than delay the current draft.

[Brian Campbell]

I agree with what Dave is saying. The "limited set of plain text characters" doesn't have a strict definition (and RFC7994 isn't referenced or really applicable). It's really just intended as guidance to be reasonable. We could consider an error code for a binding message that the OP can't/won't accept. However, invalid_request could also be used. Perhaps some text explaining that the OP can reject a binding message with that or a new code is warranted?

[Joseph Heenan]

I think I'd push for a new error code. Banks are very resistant to returning any useful error information until it is explicitly required, and "invalid_request" isn't enough for an RP to guess "ah, they must not like my binding message!".

I think (unless it's already stated) that we should explicitly state that the value is utf8, to allow use of Kanji/similar in the countries where those are the norm (for that matter someone is going to try to shove emoji in there and using a unique pattern of emojis is not actually a completely crazy idea - the whole "horse battery staple" concept).

If "limited set of plain text characters" doesn't have a strong definition I wonder if text more along the lines of "the OP should communicate to the RP what kind of binding messages are acceptable, this spec does not define how that communication happens, the general expectation is that this would be relatively short and use a limited set of utf-8 encoded plain text characters".

[Brian Campbell]

Discussed on Jan 8th 2019 call http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20190107/001408.html and the minutes say "Dave and Brian To propose some text before the end of the week" and as I recall that text was to largely be about including a new error code for the authn error response https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0-01.html#auth_error_response

[Brian Campbell]

pull request #58 has proposed text with a new invalid_binding_message error code that can be used on the Authentication Error Response if the binding_message is unacceptable for whatever reason.

[Takahiko Kawasaki]

L519

across the consumption and authentication device ->
across the consumption and authentication devices

or

across the consumption device and the authentication device

[Brian Campbell]

went with "across the consumption device and the authentication device" in 98b5635 to update pull request #58

[Brian Campbell]

7ded1f9