as promised on the call last week I tried to create a high level Archimate model focusing on the participant management in a network. Based on the input from Dennis below and our discussions on the call this is my first version. I have created separate roles
that provide the management services to the participant / SMP SP and the management of the actual DNS records. As Philip mentioned there is thinking in Peppol about the possibility to implement an authorisation mechanism for registrations. I agree that such
a function would be a good (maybe even neccesary) addition to the network and therefore I have added the
Participant Registration Authority role.
As these are "just" roles the model doesn't make statements on how actual actors will provide these services. When going one step further in the analysis and focusing on the application layer it could be possible, as we discussed during the calls, that actors
work together to implement the Participant SMP Location Lookup service.
I hope this model helps us in discussing the requirements for a next version of the BDXL. If we can agree on this high level we can analyse the functions in more detail to see what exactly needs to be specified in a standard to enhance interoperability,
both within a network and even across.
NONCONFIDENTIAL // EXTERNAL
Per the conversation today I am sending out what I posted May 6th in the chat window to the team.
Ability to update DNS along with multiple BDXL services without causing conflict
Ability to prevent unauthorized or accidental changes to participant entries
Ability for participants to migrate between BDXL providers
Ability to maintain the discovery process for a participant, regardless of BDXL dns design
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:
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,
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
Platform Engineer, Technology and Risk Group
“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.