[Openid-specs-ab] Language Script Tags

Vladimir Dzhuvinov / NimbusDS vladimir at nimbusds.com
Thu Mar 14 19:27:21 UTC 2013

Hi Justin,

You can have a look at the Nimbus LangTag library:


It was created specifically to address our need for constructing and
parsing language tags in OIDC. Some of the parsing logic is however
found in the SDK, you'll probably have to dig for it in the source code.


Vladimir Dzhuvinov : www.NimbusDS.com : vladimir at nimbusds.com

-------- Original Message --------
Subject: [Openid-specs-ab] Language Script Tags
From: Justin Richer <jricher at mitre.org>
Date: Thu, March 14, 2013 3:10 pm
To: "openid-specs-ab at lists.openid.net"
<openid-specs-ab at lists.openid.net>

In implementing things, I've run into a problem when looking to parse 
values with the language script tags and I'm wondering what other 
developers have done.

Specifically, the hash tag (#) is not a valid member name in JavaScript,

Python, PHP, or Java (and likely many others), which means I can't do a 
simple JSON-to-Object deserialization on any fields that use this 
construct. In other words, say I've got this JSON:

 { "client_name#en-us": "Test Client" }

Parsing that to JavaScript, I'd expect to be able to use the object 
accessor, like:


But that's not valid JavaScript. Yes, I can use array accessor notation,

but it's inconsistent with other fields. Similarly in Java, I'd get 
something like this in a blindly-mapped object:


but that is also not a valid Java method name. It's the same basic story

on just about every language I've poked at in the last few minutes here,

so I can't be the first one to have run into this. What has everyone 
else done to overcome this limitation in the common parse/map operation?

Do you have custom parsers that map the field names? Do you just not use

object-level accessors for these fields?

 -- Justin
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net

More information about the Openid-specs-ab mailing list