Clearer Binding Message Verification

[Ryo Ito]

The current specification does not define how much the OP will do the validation when the Client specifies the binding_message.
The requirements will change depending on the use case, such as user-verified or system-verified.
I also think that user selection of Binding Message, which is used by MicroSoft and Google, is worth including in the CIBA specification.

I propose a few parameters to make binding message validation mandatory.

• binding_message_verification_required

  • OPTIONAL. Specify true if the Client requires the OP to validate the binding_message. If it is not, it is up to the OP to validate the binding_message or not.

• candidate_binding_messages

  • OPTIONAL. A list of “binding_message” to be used for User Selection. This list must contain the value specified in “binding_message”. “binding_message_verification_required” is true and the OP must perform User Selection if this value is specified.

Details : https://ritou.medium.com/binding-message-verification-and-candidate-list-parameter-in-oidc-ciba-90ffcefa6665

‌

[Siva Boyalakuntla]

‌

Note: Edited text a little bit different from my e-mail . apologies for any typo errors in advance.

I believe, the text mentioned in the specification clearly says it must be as an example  LIKE  from specs ….  “value of reasonable entropy (e.g. a transactional approval code….@@”. 

If my transaction is log in,  some entropy I might be using  “786786” on both consumption and authentication devices to bind them together.  As per Ryo’s email  binding_message can be created by the client (RP) or  SERVER(AS) with additional verification.  

‌

1. If the server creates binding_message,  there will not be any ambiguity for that transaction. The server can choose anything to display. It is responsible for communicating. The server can display the verified binding message ( entropy) on both the devices. ( No Problem)

2. If a  client provides a list of bindig_messages to display on the authentication device and user supposed to select, this is also possible.  As per Ryo’s email, “USER SELECTED MESSAGE”, I assume the flow will be during registration user must have already selected required personalised binding message(s) for that transaction. So, it sends a possible list of client messages to the server in the client's request. The server will select “configured” personalised binding message from the list. If it doesn’t have it, then will display its own. ( fall back mechanism on failure)  , 

\ I am not assuming the user will get a list of the message during runtime through the existing profile parameters without prior registration with an approved list.

So the parameters will be  OR binding_message altogether will be removed only two Ryo's mentioned parameters will be there in the profile. 

Binding_message = “deleted” will not be used.

*binding\_message_verification_required ** TRUE/FALSE  - if true, then take the binding message mentioned in the binding_message list otherwise manage its own. 

Question: which binding message must be taken from the list for that transaction ?? are you saying multiple messages for the same transaction say “ Login” ??

• **candidate_binding_messages** -- @Siva : “ARRAY OF REGISTERED BINDING MESSAGES”.   I assume.

If the verification required is true, the server will match the configured user binding message on the system and display it.   Again it also depends on authentication device space. 

@Siva:@@@However I feel this isn't very easy and workaround, instead we can have a clean implementation like the following:: 

1. client_name: the client’s legal name to be displayed on the device. (always should be displayed)

2. Binding_message = “provide something with limited length” ( ex. Short entropy) always provided by the client. The server given by client should ALWAYS display this.

3. Client_transaction_messages = “xxxxxxxx” ( a list of transaction display messages”)  - based on the use case, not the binding message, but a separate transaction messages.   ( a list of pre-registered messages)

4. Client_verification_required:  true/false; if true,  along with client provided transaction message,  binding_message will be displayed... False, it is up to the server to decide what to display. It may respect client parameters and do not respect client parameters.

The ultimate display will be binding_message+client_transaciton_message on authentication device, on consumption device will be binding_message+ “verify your mobile to access the system”. 

`in this way, end-user/ client/server will have full control over prior registration content, and the user will have control of what to display.  Visually every end-user can inspect, what the user has registered. If verification required is true, binding_message must be used to display on both the devices, client_transaction _messages will be displayed on the authentication device.   FEATURE Phones usage for online transactions is minimal in the current generation, so space is not a problem, I believe. 

‌

I have constructed parameters based on Ryo’s mail :

‌

1. binding_message_verification_required : true
2. candidate_binding_messages: “786786”, “Login” Question: Which one should be displayed from the list?

‌

MY proposal :

1. client_name: My Telecom ( always displayed )
2. binding_message: 786786 ( always displayed); client and user will know they are coming from the ultimate end service provider
3. candidate__messages : (“Login”, “ user authentication:”) – LIst ?? why need more probing
4. binding_message_verification_required: true ; ( if true validate candidate messages) false, it is up to the server what to display.

‌

Problem with the list: If we provide a list to the server, the server can only verify whether the list of messages is already registered or not. But it does not tell you which one to select to display.

Solution One of the solution to the above problem is for that mobile account mobile user must have selected a pre-configured text when he is registered with client and server for that transaction ( example: login). Then the only server can select one message from the list. I do not see any other login of sending GROUP of messages to the server from the client.

Another solution for this problem for transactions sending SWIFT language-like codes to the server where the client has no need to send the list of messages, instead of a simple list of SWIFT like code(s) which will resolve the problem.

So selecting client_binding_messages from the list will go against the binding_message concept itself.

When writing this specification, authors might have considered feature phones; however, in this smartphone era, using feature phones for mobile authentication, is ancient school technology, I do not know whether ppl will use it or has knowledge.

‌

I believe from the beginning, the authors always misunderstood the concept of binding_message usage in authentication profile. Request to reconsider the specs and modify accordingly.

Thanks for your time.

Best Regards,

/Siva

‌

[Brian Campbell]

Some thoughts:

Although CIBA is still a draft there are implementations, deployments, profiles, conformance tests, etc. of it now. Because of this, the WG had previously agreed that the bar for making changes would be high.

Anyway, CIBA is a tricky one. It attempts to define an abstract interface between the consumption device / client and the AS/OP without imposing too many assumptions on the capabilities and nature of the authentication or consumption device themselves. I believe the proposal here places too much knowledge and expectation about the authentication device onto the client.

This kind of select from list behavior at the authentication device could potentially be accommodated without changes to CIBA by sending a binding_message and having the AS side include that value in the list of choices. It’s not ideal but similar to the proposal in terms of leaky abstraction and fragility. And without a change to spec.

If we were to make a change to CIBA to better support this kind of authentication device interaction, I’d like to consider a somewhat different approach of introducing a new parameter to the Authentication Request Acknowledgement that could convey some info about how to complete the authentication process to the user. Call it user_authn_instructions for lack of a better name at the moment. Using the Microsoft example, a response to an authentication request might look like this:

‌

    HTTP/1.1 200 OK
    Content-Type: application/json
    Cache-Control: no-store

    {
      "auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1",
      "expires_in": 3600,
      "interval": 2,
      "user_authn_instructions" : "Tap the number you see below in your Microsoft Authenticator app to sign in. 84"  
    }

Which would allow the client / consumption device to show something like:

‌

‌

while the authentication device prompts with:

‌

‌

‌

‌

[Siva Boyalakuntla]

Hi,

the Microsoft example usage is a little bit different compared to the binding_message and client_messages that are proposed to incorporate in the profile. ]

In Microsoft Example: Two different messages are being displayed in the consumption device and authentication device. To convert this example directly to the binding message might have difficulties. However, to retain existing implementations and binding_message concept intact, I would propose the following::

0. client_name: MANDATORY, a registered client name by the client with the server.

1. binding_message: MANDATORY, as defined in the profile, is a short entropy to display on both consumption and authentication devices.

2. client_messages(s): an OPTIONAL message given by the client ( RP ) to display it on the authentication device.
3. client_message_verifiication_required : OPTIONAL true/false : if true then _client_messag_e is mandatory. if false, client_message is a non-mandatory item.

Existing implementations: no need to change anything.

Any new implementations: they are free to use or not to use client_message(s) and client_message_verified parameter which are any way OPTIONAL. AS suggested by Ryo Ito, there is no harm to introduce OPTIONAL parameters that can go into MODRNA, CORE CIBA profiles.

PS: If WG had decided to bar any future changes, on NOT a finalized specs is not a good idea or recommendation. Members are now requesting some extensions that should be respected and considered on not finalized specifications from a global standards working group point of view.

In My humble opinion, if Microsoft and Google are implementing this functionality in a certain way, why OIDF is barring it from implementing it in a generalized way ?? is there any specific reason ?? do we have security issue ?? or technical issue ??

With the above optional extensions how existing implementations will become VOID ?? or complicated ??

PS: The Protocol specifications should be general, and business use cases will decide how to use the protocol with extensions. Please see CIBA is being used in Finance and Mobile operators world. So, the proposed extensions apply to multiple domains. Instead of a specific use-case, wherever applicable WG should allow broader and domain-independent extensions that are OPTIONAL that do not impact any existing implementations. From a standards body like OIDF these are good practices to follow does not discourage the majority of the OIDF members.

I think these are good extension OPTIONAL proposals and will be useful to many use cases in different domains.

Thank you in advance for considering this concept.

‌

Best Regards,

Siva Boyalakuntla

BRUHASPATHI LTD.

[Brian Campbell]

The approach I mentioned would also allow for things like “select the picture of a dog” or “choose all the images with a stoplight” or “tap on the triangle” or “enter the answer to 4+3” etc.

[Dave Tonge]

I agree Brian, I’m not keen to change the protocol to support a single binding message implementation.

[Dave Tonge]

@Siva client_name is not to do with CIBA, it can already be provided as part of dynamic registration: https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata

[Joseph Heenan]

Thoughts from today’s call (mostly thinking about Brian’s proposal):

We’d need to support internationalisation (possibly the same way claims can be returned in multiple languages in OIDCC core) for the returned message.

Some consumption devices might not be capable of displaying the message or some types of messages.

In some scenarios there might not be a consumption device.

The new user_authn_instructions should probably be mutually exclusive with binding_message, as it doesn’t seem to make sense to use both of them.

[Brian Campbell]

We’d need to support internationalisation (possibly the same way claims can be returned in multiple languages in OIDCC core) for the returned message.

Internationalization in CIBA is tricky due to the different pieces in play but I don’t think this prospective parameter needs any special or additional support. The client can convey it’s preference(s) with Accept-Language in the Authentication Request so the AS can i18n the response accordingly. Furthermore the AS has to identify the user and their appropriate authn device so could have access to user or device language preferences, if it saw fit to use that to i18n the message in the response.

‌

Some consumption devices might not be capable of displaying the message or some types of messages.

This is a legit concern. As are clients that are implemented against the existing version of the spec and have no knowledge of this message. I see that as an argument for not doing anything here, however. Ryo’s suggestion flips the problem around (some AS’s or authn devices can’t do the select from list thing) but doesn’t alleviate it.

‌

In some scenarios there might not be a consumption device.

Like the customer service rep on the phone? I’d presumed the rep would have to convey the message to the user. But other no consumption device cases would suggest the same as the privious reply - maybe we shouldn’t be accommodating this in the spec.

‌

The new user_authn_instructions should probably be mutually exclusive with binding_message, as it doesn’t seem to make sense to use both of them.

Probably true but I don’t know that it needs to be made explicitly exclusive.

[Siva Boyalakuntla]

Hi,

Apologies for not attending today’s call, I was stuck in other calls today. Got free time now :

%%Brian%%The approach I mentioned would also allow for things like “select the picture of a dog” or “choose all the images with a stoplight” or “tap on the triangle” or “enter the answer to 4+3” etc.

@Siva: Yes, agree with Brian. It is also possible—

some other thoughts. As per Ryo’s post, I can see that the business case requirement gives flexibility to client provided messages through client_message(s) and verified flags. Btw, the proposal will also work with the browser-based protocol and CIBA based protocols. The concept applies to both scenarios.

for Internationalization agrees with Brian’s comments.

%%Joseph%% Some consumption devices might not be capable of displaying the message or some types of messages. In some scenarios, there might not be a consumption device.

@Siva: There are two concepts when consumption device exists, and the second one consumption device does not exist.

Consumption device: what are the capabilities of the consumption device to display simple text is. The main concern is who will display the message on consumption device? If consumption device exists, AS will display the consumption device page. So, the control will be with AS feven for internationalization. Agree that all types of messages may not be possible to display, but that is applicable to all specifications written by OIDF, wherever consumption device is involved. Sending simple text through client_messages is not a problem to display on consumption device.

Authentication device: again, the question who will display this message? Of course AS. Whether it is a mobile APP or feature phone text messages, OP ( AS ) can display client messages. Again this applies to all OIDF mobile specs. If we do not have a problem with other specifications displaying the TEXT, it should not be a problem for Browser-based OR CIBA specifications.

Now, my query is do we need to display client_message ALWAYS on consumption device OR ALWAYS on authentication device ?? I assume the client_message(s) is a personalized text by RP for that user or use case displayed on the authentication device ALWAYS. But, it is not necessary to display on consumption device. It can simply say on consumption device “<binding_messsage>+Look your mobile for the message”. etc. On Authentication device it will be “<binding_message> + client_message”, SO why to worry ??and that too optional. So I do not see any problems regarding this.

Regarding space: if consumption device space is a concern, there will be more space on consumption than an authentication device. If language / or special types of messages are possible to display an authentication device, it can also be displayed on the consumption device. I believe mobile operators SIM APPLET implementations will have less space on authentication devices ( minimum available space globally ).

some publicly available information: https://1ot.mobi/resources/blog/iot-hacking-series-6-what-is-a-sim-applet-and-why-is-it-important-for-iot-m2m

This feature will give more flexibility to RP ( clients) to personalize the user experience.

Pardon me, and I am not good with web page character display concepts. Following is an imaginary scenario :

If I am using Japanese windows laptop and client (RP) is sending a Japanese character. Then there will not be any problem, since locale will support these characters however if I am using Chinese windows laptop and receiving Japanese characters if the page that is being displayed on a consumption device might not support all characters—similarly English windows laptop and receiving Chinese characters, until and unless multi-language support is enabled. ….”, . So in the specifications if we add the TEXT”……. depending on the capabilities of consumption and authentication devices……” which will be future proof and RP/client and OP/server can understand the limitations of the specifications. For mobile profile we can capture implementation guidelines.

‌

Consumption device does not exist: If consumption device does not exist, there will not be any problem at all. if we include these parameters, then we need to say in the specs ..”……depending on the capabilities of the consumption and authentication devices

%%Joseph%% The new user_authn_instructions should probably be mutually exclusive with binding_message, as it doesn’t seem to make sense to use both of them.

@Siva: No, this is not true. The concept of binding message and client messages with the verified flag is different. Joseph has misunderstood it. please see below example :

consumption device: <binding_message>+” Look your mobile for instructions.”

authentication device : <binding_message> + <client_message(s)> ( always ) , so THEY ARE NOT MUTUALLY EXCLUSIVE parameters.

%%Dave Tonge%% Siva client_name is not to do with CIBA, and it can already be provided as part of dynamic registration

@Siva: Thank you. I am still going through all specs, still studying. Then there will not be any problem since from metadata AS can take the client_name.

%%Dave Tonge%% I agree with Brian, I’m not keen to change the protocol to support a single binding message implementation.

@Siva: I think no need to change the protocol flows OR they are not mandatory parameters. I think PROTOCOL is not changed at all. If we include these OPTIONAL parameters in both browser-based and CIBA based, then there will not be any problem to the protocol flows or existing implementations. Probably my guess is dynamic client registration for client messages metadata might change ?? not sure.

So, coming back to my iews :

1. binding_message: MANDATORY, as defined in the profile, is a short entropy to display on both consumption and authentication devices.
2. client_messages(s): an OPTIONAL message given by the client ( RP ) to display it on the authentication device.
3. client_message_verifiication_required : OPTIONAL true/false : if true then _client_message is mandatory. if false, client_message is a non-mandatory item.

‌

Thanks for reading long mail and for your patience.

‌

best regards,

/Siva

‌

[Charles Marais]

Hello All,

A few comments on my side.

In my understanding, this thread started with the objective of improving the interlock mechanism in server to server flow (CIBA) with a check enforced by the OP in order to offer system-verified mechanism. For example :

• binding_message : 84
• binding_message_verification_required : true
• candidate_binding_messages : [84, 74, 56]

The goal seemed to be pretty clear but the thread shifted to a totally different topic, IMHO, where the proposition is to display an open message “client_message” on the authentication device, and that for both CIBA and browser-based flows. I do think that we are mixing two different topics which should probably be dealt in two different issues.

Concerning the “client_message”, the main attention point is to make it clear that the user is in a journey with potentially 2 goals (roles of the OP) :

• authentication on the OP in order it (the OP) will transmit a proof of this authentication to the RP (the id_token).
• consent on the OP for several scopes which will allow OP to deliver an access token (matching these scopes) to consume some resources (on OP side or the entity for which it operates)

Several points could be important to evaluate :

• The 2 tokens (id_token and access_token) provided to RP by OP after this journey should not be interpreted beyond there semantics. For example, not to be interpreted as a response if the “client_message” was a question…
• The messages displayed on authentication device should be controlled by the OP in order to avoid abuses of its users. The client_message probably cannot be dynamic, in order to avoid : “Enter your pin to win $1.000.000 !“. This is more than true in a browser-based flow not using signed request for which the request is public and editable !
• So probably, if a RP-customized message is required to be display during authentications, it should be preregistered statically (or through controlled patterns) during registration step of the RP. This way it could be controlled by the OP.

Br,

Charles.

[Siva Boyalakuntla]

Few points :

0. The example given above is only for one example. Introducing client-message is more generic and applicable to many business use cases using the OIDC protocol, which can also be used for any actions. ( as stated in our discussion some images for example)

1. OIDF always allows extensions for implementations. For example, please see below diagram where OIDC protocol is used for any actions provided by the user. The response is still through ID Token and minimal effort for existing implementations. This is integrated by `Microsoft azure AD. The OIDC protocol is famous so that its flows, especially Authorization server flows, ID Tokens are used extensively. If you read the provided Microsoft Link, you can see the correct steps how efficiently they are using and integrating with AZURE AD by Microsoft. Whenever AS Microsoft contacts, the user always uses Authorization Server flows and ID Token to return the information based on actions. They have also integrated Operators provided APPs too. Such industry leaders like Microsoft always allow user should be contacted by using authorization servers. Non-OIDC protocols can contact in other methods. Which is not restricted by OIDC.
2. Also, Brian has given some Microsoft examples too. I think the protocol should be flexible enough to use OIDC features efficiently.
3. The publicly available link from Microsoft is here: Here is the example link to how Microsoft cloud is partnered with Telecom operators:: https://docs.microsoft.com/en-us/azure/active-directory-b2c/partner-itsme
4. In short, Microsoft always contacts the user for any acton through AZURE AD / OIDC AS servers. They must have looked into all possibilities regarding security. Technical aspects point of view. And this is integrated successfully in azure cloud environments. So, usage of ID Token is already in the industry nothing new.

4. As you can see, there is NO user info request if you read the link the integration is done by using the authorization servers only. `This confirms single AZURE AD integration, always user is contacted through authorization server and required information is returned through ID token ( one can read the Microsoft docs and the steps ) for any action.

‌

coming back to our concepts::

5. client_message can be dynamic but only respected if the clent_verified flag is true, and trust policy is enforced between client and server. I think the dynamic client registration profile should be changed to integrate metadata.

Please see if the proof is not provided through ID Token for client_message, but if any implementation would like to use OIDC protocol to provide proof back to the client, then there is no restriction always it is possible.

6. Regarding browser requests and manipulations, we always recommend signing requests if we use this client-message and verified flags. Probably signed and encrypted message in the browser related messages. Adding a security recommendation will restrict the implementations.

7. for our reference extracted point from Microsoft publicly available documentation :

8. I think the conclusion should be “PROTOCOL SPECS SHOULD BE FLEXIBLE ENOUGH TO INCORPORATE ANY BUSINESS USE CASES” but “ BUSINESS USE CASES SHOULD NOT RESTRICT THE PROTOCOL OR SHOULD NOT BE NARROW-MINDED” for any standard in the technical world. Hope we all already understand this concept.

‌

Best regards,

/Siva

[Ryo Ito]

Thank you for all the comments.

I should have asked only this question first.

"Should such simple authentication, which is similarly implemented by Google and Microsoft (outside the standardized protocol), be defined as part of the standardized protocol?"

If the answer to this is YES, then

"Who will generate the list of candidates and answers?"

• Client

  • Can we use the existing Binding Message as the correct answer value to achieve this, with an additional parameter for the list of candidates? -> My suggestion.

• AS

  • AS determines the content of such additional authentication and returns "user_authn_instructions" to Client <- Brian's suggestion

Even if your first question is NO, Brian's suggestion would be a generic way to achieve additional authentication.

I don't disagree with it, but I feel that I would like a request parameter that would allow the Client to request this additional authentication.

[Siva Boyalakuntla]

Hi,

few thoughts :

\%%Ryo%%

Who will generate the list of candidates and answers?"

• Client

  • Can we use the existing Binding Message as the correct answer value to achieve this, with an additional parameter for the list of candidates? -> My suggestion.

@Siva: Agree client should send the list of candidate answers. If the binding message is used for the list of candidates, then it will be confusing means the purpose of the binding message will become void I believe i.e. binding consumption device and authentication device. i do not think binding message as the correct answer value, is the correct design.

‌

\%%Ryo%%

• AS

  • AS determines the content of such additional authentication and returns "user_authn_instructions" to Client <- Brian's suggestion

@Siva: maybe a different name to return it. Please see we can use ‘generic' naming convention since CIBA OIDC and Browser-based OIDC are used for several business use-cases not only simple authentication.

I still support client_message and clent_message_verified parameters as OPTIONAL. addition to binding message parameter.

\%%Ryo%%

I don't disagree with it, but I feel that I would like a request parameter that would allow the Client to request this additional authentication.

@Siva: I agree, to have an additional parameter in the request.

‌

[Charles Marais]

Hello,

Once again. Ryo, like Brian are talking about a mechanism for interlock verification between consuming and authentication devices during authentication kinematic.

@Siva : Not sure to have well understood your demonstration with Microsoft and Its’me… Definitely, the ID token is an authentication proof signed by the OP following an authentication of the user. Details (date, method, level, etc…) about realised authentication may be embedded in the ID token as it may be the case for user information related to the authenticated user.

I still don’t see how your proposal with client_message / client_message_verification_required solve this issue. I rather see a mechanism to oblige the OP to display a dynamically pushed text proposed by the SP in the authentication journey on the OP. If this is the case, my proposal was to deal with this point in a separate issue.

Br,

Charles.

[Siva Boyalakuntla]

thanks, Charles. Few more points :

Any protocol specification should include generic parameters that can allow innovations by the implementors. We do not know how future or existing business will use it/ turn out to be. It solely depends on the creativity of the innovators.

using a single binding_message parameter to complicate the specification is not a good choice.

1. binding_message solely to be used as a SHORT entropy to interlock two devices. It must be used accordingly without disturbing current implementations. And it handled by AS. provided by RP.
2. anything extra or selection then it must be through different parameters for cleaner implementation.

See the previous comment from Dave Tonge.

%%Dave%% I agree Brian, I’m not keen to change the protocol to support a single binding message implementation.

@Siva: if I understood correctly single binding message implementation (like selection)for different purposes will complicate the specification. So, I support introducing new parameters in the specification by extending OPTIONAL parameters which can also be used for multiple business use cases.

we need to think about existing implementations too. if client_messages and the verified flag are true, then simply ignore the binding_message and use the selected message is one way of doing it.

But a few questions :

1. who will select it ?? is it done on the authentication device or consumption device ?? selected by the user at runtime?
2. when will the option to select a binding message to be displayed on the consumption device or authentication device? before displaying the action text or along with the action text? ( assuming consumption device exists)
3. then how the binding message is an interlock message?? if any action is displayed on the devices even for selection. ??

So, thinking selection for a binding message with exiting binding message seems confusing to me. instead using generic separate parameters for general purpose is my choice.

PS: This should have been done by the authors initially/ long back and we know why extra parameters are not used then -:), as I was saying parameters are used in different types of use cases for different purposes in the near future times -:). we are living with it by not thinking future use in the past -:)).

So, i support using separate generic parameters for multiple purposes if it is there any selection that can help businesses who use OIDC CIBA.

best regards,

/Siva

‌

[Petteri Stenius]

The CIBA specification is extensible and does not stop innovating for example new safer and more user friendly binding message verification protocols.

This proposal can easily be written as an authentication device vendor specific extension on top of CIBA, by prefixing the new parameters with companyname_ as defined in OAuth 2 (https://tools.ietf.org/html/rfc6749#section-8.2)

[Dave Tonge]

I’ve created this PR to make it clear that the profile can be extended: https://bitbucket.org/openid/mobile/pull-requests/13/add-text-around-extensability

We discussed on the call today that this proposal, while very interesting, probably doesn’t belong in CIBA core.

We would be welcome to continue the discussion on MODRNA WG calls - perhaps a small extension to the spec could be drafted if there was enough interest.

[Bjorn Hjelm]

I agree with Dave’s recommendation and the working group can entertain any future discussion on extension if there is interest.

[Dave Tonge]

PR merged