feat: auth Server should Support Client Registration Language Metadata

[nynymike]

Section 2.1 of OpenID Client Reg states:

Human-readable Client Metadata values and Client Metadata values that reference human-readable values MAY be
represented in multiple languages and scripts. For example, values such as client_name, tos_uri, policy_uri, logo_uri, and
client_uri might have multiple locale-specific values in some Client registrations.

To specify the languages and scripts, BCP47
[RFC5646] language tags are added to Client Metadata member names, delimited by a # character. The same syntax is used
for representing languages and scripts for Client Metadata as is used for Claims, as described in Section 5.2 (Claims
Languages and Scripts) of [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-registration-
1_0.html#OpenID.Core) [OpenID.Core].

If such a human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the
language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a
user interface. To facilitate interoperability, it is RECOMMENDED that any human-readable fields sent without language tags
contain values suitable for display on a wide variety of systems.

• The highest priority claims are client_name and client_uri.

[qbert2k]

The Client metadata values: client_name (displayName), logo_uri (jansLogoURI), client_uri (jansClntURI), policy_uri (jansPolicyURI), and tos_uri (jansTosURI) now stores a JSON with values for multiple languages and scripts. For example:

MySQL, Couchbase, Spanner, etc.

client_name (displayName)

logo_uri (jansLogoURI)

client_uri (jansClntURI)

policy_uri (jansPolicyURI)

tos_uri (jansTosURI)

LDAP

LDAP has support for Language Tags

[nynymike]

This is an interesting feature. Let's make sure it gets listed in the internationalization section of the docs.

[yurem]

This #1482 problem related to this ticket.

LanguageTag should support read from DB and search in filters.

Why ORM layer should know how to handle specialized LanguageTag annotation? ORM has generic solution to work with JSON objects. Instead of this:

    @LanguageTag
    private LocalizedString logoUri = new LocalizedString();

We can use:

    @JsonObject
    private LocalizedString logoUri = new LocalizedString();

[qbert2k]

Hi @yurem
The LocalizedString is handled as JSON for MySQL, Couchbase, Spanner, etc.
But, LDAP has support for Language Tags so it is not handled as JSON.
That's the reason I have created a new annotation @LanguageTag to be able to perform a different treatment according to the case.

#1482

[yurem]

I saw your implementation for LDAP. In this case ORM based on server functionality. But in all other cases there is no in DB special support for language tags, etc. LDAP is losing it's positions in CE. I think in this case there is no major point to implement something special for it.

For me @LanguageTag == @JsonObject . In both cases we store data in JSON. @JsonObject we already support in setup in all projects, etc.. For me is better to use one @JsonObject to keep ORM layer sampler for support.
Can you share special case which you mentioned in last comment for discussion?

[yurem]

If you need to implement special behavior you can use 2 or more tags. Sample:

    @JsonObject
    @TagForSpecialBehaviour
    private LocalizedString logoUri = new LocalizedString();

[Milton-Ch]

Looks like there are many tests that are failing because of this issue, do we have some fix coming?
https://jenkins.jans.io/jenkins/job/jans-auth-server/6661/

[yuriyz]

@qbert2k where are with this issue? It still effects integration tests and keeps as blind with server functionality overall. Can you take it as priority?

[qbert2k]

@yuriyz
I cannot reproduce locally, also I tried from a fresh dev env. The claim is returned normally after client registration.

I will contact you by chat with more details.

[yuriyz]

@qbert2k does tests work ok for you ? It does not on jenkins as you can see.

[Milton-Ch]

In tests, we have this test that couldn't validate properly client_name.

In the stack trace we can see that it's failing while validating asserts.

at org.testng.Assert.fail(Assert.java:96)
at org.testng.Assert.assertNotNull(Assert.java:686)
at io.jans.as.client.client.Asserter.assertRegisterResponseClaimsNotNull(Asserter.java:32)
at io.jans.as.client.ws.rs.AuthorizeRestWebServiceHttpTest.requestAuthorizationAccessTokenFail(AuthorizeRestWebServiceHttpTest.java:2096)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:124)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:583)
at org.testng.internal.Invoker.retryFailed(Invoker.java:839)

[qbert2k]

I will keep checking...

[yuriyz]

@qbert2k no need to check. I've debugged it, the root cause was actually in NPE in JwtAuthorizationRequest. I've fixed it, so next re-build should show tests state. So this language ticket has nothing to do with current tests failures. I will keep an eye on tests.

For reference #1641

[qbert2k]

great!