ToU consent broken in combination with multiple languages

Let's assume we want to configure a single ToU statement and we would like to present it in multiple languages, depending on the user's browser settings.

For such a multi-lingual scenario, the current v3.3 configuration capabilities have two major limitations:

a) The key for the hash is based on the .text property and that results in different hashes when multiple languages need to be supported!

b) It is currently not possible to configure some other value than '.text' to be used as key
in the user configuration (${idp.home}/conf).

Although the class net.shibboleth.idp.consent.logic.impl.MessageSourceConsentFunction
would allow to set a different suffix, neither the system configuration (${idp.home}/system)
nor the user configuration (${idp.home}/conf) allow to set a different suffix.

We propose to fix this in the system configuration, e.g. as follows in
${idp_home}/system/flows/intercept/terms-of-use-beans.xml:

{{ <bean id="TermsOfUseConsentFunction"
class="net.shibboleth.idp.consent.logic.impl.MessageSourceConsentFunction"

• p:consentKeyLookupStrategy-ref="shibboleth.consent.terms-of-use.Key" />
  + p:consentKeyLookupStrategy-ref="shibboleth.consent.terms-of-use.Key"
  + p:consentValueMessageCodeSuffix=".text" />
  %{idp.consent.terms-of-use.consentValueMessageCodeSuffix:.text}
  }}

And additionally in ${idp_home}/conf/idp.properties:

{{+# Suffix of the message property to be used as key to store the consent.
+# Default is to use the text that is shown to the user.
+#idp.consent.terms-of-use.consentValueMessageCodeSuffix = .text
}}

As a current workaround we introduced a new .html property (see below), but it would be more straightforward to make the property configurable that gets used for the key, e.g. .version.

We adapted the following in consent-intercept-config.xml:

{{<alias alias="shibboleth.consent.terms-of-use.Key" name="shibboleth.SingleTermsOfUseText" />

<bean id="shibboleth.SingleTermsOfUseText"
class="com.google.common.base.Functions" factory-method="constant">
<constructor-arg value="my-terms-of-use" />
</bean>}}

and we originally included in messages.properties:

{{my-terms-of-use = my-tou
my-tou.title = Example Terms of Use
my-tou.text = <p>Example organization Terms of Use (ToU)</p> \ <p>Lorem ipsum dolor sit amet, \ consectetur adipiscing elit. \ </p>
}}

The key is the .text property. As soon as we add the my-tou.text property in additional languages, the key for each language is different!
Provided a user switches between browsers with different language settings, this user will have to accept the ToU over and over again, simply because the hash is not the same for all languages.

Our workaround for this was to introduce an additional property my-tou.text.html, see below.

So we now included in messages.properties:

{{my-terms-of-use = my-tou
my-tou.title = Example Terms of Use
my-tou.text = ToU version 1.0 - 20170405
my-tou.html = <p>Example organization Terms of Use (ToU)</p> \ <p>Lorem ipsum dolor sit amet, \ consectetur adipiscing elit. \ </p>
}}

and we needed to replace in /opt/shibboleth-idp/views/intercept/terms-of-use.vm:

this line

#springMessageText("${termsOfUseId}.text", "Terms of Use Text...")

with this line

#springMessageText("${termsOfUseId}.html", "Terms of Use Text...")

For the translations we only add the properties my-tou.title and my-tou.html into the language dependent .properties file. That way, we have a single my-tou.text property as key for the hash!

That way you can even correct a typo or a minor change that does not require a new approval in any of the languages. From now on, you only change the version information in the my-tou.text property when the legal counsel asks you to replace the current ToU version with a new one that requires approval. That has to happen in sync for all the languages.