[Identity Assurance] Giving null and/or empty strings special meanings might bring about difficulties in implementations

Sorry for bringing this topic after the public review started.

null and an empty string are different in JSON. However, some computer languages and libraries for JSON mapping cannot distinguish them. Some libraries cannot tell even the difference between null and an empty array.

I have experience in writing OAuth/OIDC libraries in Java, Ruby, C#, PHP and Python. And recently, I wrote one in Golang. I learned that the string type in Go cannot be nil. As a result, Golang cannot tell the difference between null and an empty string in JSON. Developers may be able to achieve it by using string pointers (*string) instead of string or by developing a custom mechanism for nullable strings (StackOverflow: “Assigning null to JSON fields instead of empty strings in Golang“), but it would drastically damage usability of Golang libraries. You would agree on the usability issue especially after you notice that Golang doesn’t allow developers to get pointers of string literals in this form: &”literal”. The Golang’s standard library “encoding/json” which is used for JSON mapping provides a mechanism to exclude JSON properties whose values are empty strings from generated JSON (by adding the omitempty tag). However, still, this cannot tell the difference between (1) “the property exists but its value is null” and “the property does not exist”.

An actual case: Some Authlete APIs behave differently when a certain input parameter in JSON is null (or not given) and when it is an empty string. However, I gave up distinguishing them in the client library written in Go (github.com/authlete/authlete-go).

In some parts in the specification (OpenID Connect for Identity Assurance 1.0, draft-07), null is given a special meaning. For example, 5.1. Requesting End-User Claims says “Note: A claims sub-element with value null is interpreted as a request for all possible Claims.” However, I think that it would be better to devise a more explicit way for the special purpose. Otherwise, some implementers might face computer-(language|library)-specific troubles and restrictions.

‌

Comments (5)