[Openid-specs-ab] Issue #1110: [Identity Assurance] Giving null and/or empty strings special meanings might bring about difficulties in implementations (openid/connect)

Takahiko Kawasaki issues-reply at bitbucket.org
Tue Oct 1 11:33:55 UTC 2019

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

Takahiko Kawasaki:

Sorry for bringing this topic after the [public review started](https://openid.net/2019/09/19/public-review-period-for-openid-connect-for-identity-assurance-specification-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](https://stackoverflow.com/questions/31048557/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](https://golang.org/pkg/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](https://github.com/authlete/authlete-go)\).

In some parts in the specification \(OpenID Connect for Identity Assurance 1.0, [draft-07](https://openid.net/specs/openid-connect-4-identity-assurance-1_0-07.html)\), 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.


More information about the Openid-specs-ab mailing list