OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Bus Requirements


NONCONFIDENTIAL // EXTERNAL

Per the conversation today I am sending out what I posted May 6th in the chat window to the team.

 

Business Requirements:

1.       Ability to update DNS along with multiple BDXL services without causing conflict

2.       Ability to prevent unauthorized or accidental changes to participant entries

3.       Ability for participants to migrate between BDXL providers

4.       Ability to maintain the discovery process for a participant, regardless of BDXL dns design

5.       Ability to discover participants outside the established BDXL dns, when appropriate agreements between governance organizations are in place.

 

There is a request from the team around what the governance model is for the framework in the US/NA. The BPC has not started formal governance model discussions. This question comes up quite a bit, and I do recognize that without one we are making assumptions.

 

My goal in this is to look at how the BDXL standard can be modified to support a federated model of governance, mainly being, that each federated participant (e.g. SML) has equal authority and responsibility to the rules and regulations that make up the governance. It would be what a true federated model is, in that in order to make the governance model, you need that group of participants to all come together and create the rules and regulations for that framework. In this scenario, the SML represents the registration authority and all the requirements that go with it (e.g. KYC.) On could easily argue that would be the SMP providers that do that, so for the sake of argument lets assume an SML and SMP would be the same providers, in all cases (again, just for the sake of the discussion, this is NOT by any means a suggestion.)

 

From a technical perspective, how would we use existing tools that would support a governance, with members from multiple businesses, that allows for equal authority in the framework, but ensures that each member can control the participants that are registered through them, and only through them, while maintaining the ability to support a discovery model as defined by BDXL.

 

My initial thoughts were around having an agreed upon domain name, like b2bei.org (for instance), that the governance agrees is non-partial and managed by a third party, and by managed, purely from a technical hosting perspective. Then each federated participant would have their own sub-domain that would have delegated DNS authority (i.e. company1.b2b.org and company2.b2b.org). However, I was not sure how that would affect the discovery mechanisms that already exist. This is when Kenneth brought up the secondary DNS server idea, and still a flat domain (no sub-domains). This does not address the concerns with accidental/non-authorized changes by SMLs on participants they don’t manage. However, it could potentially be addressed with standards around Business Administration APIs and creating rules that require their use.

 

What Philip brought forward today, is a really interesting idea (to me at the very least), that does support a sub-domain model, that would then allow for the segregation of those authorities into sub-domains, but as he stated, there is still a lot of unknowns. Something I feel like we should discuss further.

 

Ultimately, the technical workgroup (a consortium of BPC members) did come up with a technical recommendation to investigate the federated model, from a technical and governance perspective. Unfortunately, we are only in a position to pursue the technical aspect right now. The output of that is found here: https://businesspaymentscoalition.org/wp-content/uploads/20191031-bpc-e-delivery-network-feasibility-assessment.pdf

Page 36 is the start of the recommendations, and table 11 adds the need to do further research on developing/understanding technology needed to fully support a federated registry (not to be confused with a directory – which is just a lookup of the registry.)

 

I hope this helps further explain details. Please don’t hesitate to comment/correct on any of it. If folks have ideas on a more detailed governance model that would be welcome as well. But bare in mind, it is still all conjecture right now until something formal starts. (Which I have no control over.)

 

Thanks, and many regards,

-Dennis

 

Also, these are my views and they do not reflect the views of the Federal Reserve Bank of Minneapolis, nor the Federal Reserve System.

 

 

FEDERAL RESERVE BANK OF MINNEAPOLIS
Pursuing an economy that works for all of us

 

Dennis Weddig
Platform Engineer, Technology and Risk Group
W 612-204-6370

@minneapolisfed  I  minneapolisfed.org

 

“01000111 01000001 01001101 01000101 00100000 01001111 01001110 00100001”

 


This e-mail message, including attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]