Hi all,
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.
Groet,
Regards,
Sander Fieten
T: +31 6 51 50 78 86 skype:
sfieten
W: www.chasquis-consulting.com
Holodeck B2B | AS4 | eDelivery
Consultancy
On 03/06/2020 18:49, Weddig, Dennis
wrote:
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.
