[Openid-specs-fapi] Representing international strings

Saxena, Anoop Anoop_Saxena at intuit.com
Fri Jul 15 20:32:05 UTC 2016


General Recommendation is not to  put special char in attribute name for JSON payload as some implementation may not handle it.

From: Nat Sakimura [mailto:nat at sakimura.org]
Sent: Wednesday, July 13, 2016 10:55 PM
To: Openid-specs Fapi <openid-specs-fapi at lists.openid.net>
Cc: Saxena, Anoop <Anoop_Saxena at intuit.com>
Subject: Representing international strings


Hi

OpenID Connect introduced a variable name scheme for international scripts. For example, a name in Katakana script in Japanese will be represented as

        name#ja-Kana-JP

where "ja-Kana-JP" part is described in ISO script format.

My question to the list is whether do we want to continue using this scheme even on Swagger. As swagger cannot have # in the variable name, it would become like

        name%23ja-Kana-JP

etc. This may be OK, but there could be better ways as well, I suppose.

Another obvious ways to deal with it is to use map where the key is going to be the script name and value is the actual value for the parameter.

In any case, I need to find out how to put a variable as the key/name in Swagger definition. Those who knows Swagger well, please help.

Another issue that I have in mind is that what happens if Kanji arrives as "Name" in DDA endpoint. Would the application be OK with it or blows up? Read only case would probably be ok, but if you wanted to send money, for example, and there are Kanji in the Transfer message, what would happen to the US banking system?

Do we need to mandate the current Name like string restricted to ASCII?

Best,

Nat Sakimura





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20160715/fb0e03b0/attachment.html>


More information about the Openid-specs-fapi mailing list