Hi All suggested changes
regarding what was discussed on call today. cheers /L From:
"Sander
Fieten" <
sander@chasquis-consulting.com> To:
bdxr@lists.oasis-open.org Date:
08/09/2021
06:44 am Subject:
[EXTERNAL]
Re: [bdxr] Agenda for Pacific BDXR TC call 07 September 2021 23:00UTC Sent
by: <
bdxr@lists.oasis-open.org> Hi all, as discussed on last weeks call I would take a look at the use of the Certificate
Type Codes todo item. I checked the current document and these type codes
are currently used / referenced in 2.2.5 PMode.Responder.Party, 2.2.36
PMode[1].Security.X509.Encryption.Certificate and 5.2 The use of multiple
Access Point certificates with SMP 2.0. Sections 2.2.5 and 2.2.36
only defined one code specific for signing or encryption, but not one for
the scenario where one certificate is used for both (which I guess is the
most common usage scenario). In the attached document I have included some first proposals how we could
integrate the definition of the code list for certificate types. To prevent
duplicating text and to keep it readable, I introduced a separate section
in chapter 2 to define the code list and referred to this new section from
the other ones. Happy to hear your comments! Groet, Regards, Sander Fieten T: +31 6 51 50 78 86
skype: sfieten W:
www.chasquis-consulting.com Holodeck B2B AS4 eDelivery
Consultancy On 07/09/2021 22:34, Kenneth Bengtsson
wrote: Agenda
for Pacific BDXR TC call 07 September 2021 23:00UTC
http://www.timeanddate.com/worldclock/fixedtime.html?iso=2021-09-01T15:00:00 Pacific:
18:00MSP/01:00Europe/19:00Ottawa/23:00UTC/09:00Sydney Conferencing
info Meeting
ID: 547 975 473 Passcode:
oasis Join
from PC, Mac, Linux, iOS or Android:
https://us02web.zoom.us/j/547975473?pwd=bjVvdDhDcEZXZ3R3cldRYkpuQU13Zz09 Or
iPhone one-tap (US toll): +13462487799,,547975473#,,,,,,0#,,130346#
US (Houston) +16465588656,,547975473#,,,,,,0#,,130346#
US (New York) Or
international dial-in number (toll):
https://us02web.zoom.us/u/kchtpYJm7L Meeting
ID: 547 975 473 Passcode:
130346 Standing
items TC
Vitality The
TC must next appoint or reappoint chair(s) in January 2023. Next
TC vitality check must be made in January 2025. Review
of Pacific call minutes
https://lists.oasis-open.org/archives/bdxr/202108/msg00001.html Review
of Atlantic call minutes
https://lists.oasis-open.org/archives/bdxr/202107/msg00008.html Membership
status review
https://www.oasis-open.org/policies-guidelines/tc-process#membership Voting
status is determined by the following: -
existing voting members must not miss two consecutive meetings to maintain
voting status -
non-voting members must attend two consecutive meetings to obtain voting
status -
members formally on leave by prior request must not attend and their voting
status is not impacted Current
BDXR TC voting member list (alphabetical): -
Todd Albers -
Kenneth Bengtsson -
Erlend Klakegg Bergheim -
Kees Duvekot -
Sander Fieten -
Levine Naidoo Members
gaining voting status after this meeting: -
Dennis Weddig Members
losing voting status after this meeting: -
Levine Naidoo AS4
profile for four-corner networks The
30-day public review of AS4 Interoperability Profile for Four-corner Networks
Version 1.0 CSD01 closed on July 23, 2021 with no comments received. To
do list: -
PMode.Responder.Party: What should the sending access point do if it can t
validate the signature of a received signal message? o
Agreed to remove
the statement The sending Access Point SHOULD verify that the value
of the Subject CN field of the certificate used to sign the Receipt Signal
Message is identical to the PMode.Responder.Party ID. -
Add Certificate/TypeCode codes for encryption and encryption+signing. o
Sander will look
at this for next week -
Code list and documentation for Certificate/TypeCode. -
Multiple payloads o
Not needed for now -
Standardize Endpoint/TransportProfileID o
bdxr-as4-1.0[#NetworkPolicyID] o
Kenneth to make
a proposal for next week Overview
of the four-corner model Committee Note During
work with BDXL 1.1, Sander and Kenneth identified that elements of the
text (describing the four-corner model, its components and its actors)
would perhaps be better suited for a broader Committee Note. An early (incomplete)
draft has been uploaded here, for discussion in the TC:
https://www.oasis-open.org/committees/document.php?document_id=68197&wg_abbrev=bdxr The
TC continues to review the committee note draft. BDXL BDXL
1.0 A
ticket was created pointing out an issue with regular expressions in the
BDXL 1.0 examples. It was agreed at the TC meeting November 25 to focus
on BDXL 1.1 first, and then look at a possible BDXL 1.0 errata after that.
https://issues.oasis-open.org/browse/BDXR-29 BDXL
administration API Proposal
from Erlend:
https://lists.oasis-open.org/archives/bdxr/201905/msg00015.html There
have been discussions within Peppol regarding requirements for the BDXL
Administration API. Sander will reach out to the involved participants
to gather further requirements. Agreed
that the updated BDXL 1.1 specification will mention the BDXL Administration
API and its features for updating and maintaining BDXL records. Discussed
that the BDXL Administration API could include a section for how
to update a primary BDXL in a federated model. Steps
forward: 1)
Map the API interface from the existing specification previously submitted
to the TC (Kenneth) 2)
Describing functionality (group) 3)
Work on XML and JSON bindings (Sander, Dennis and Kenneth) Kenneth
presented a map of the Peppol SML registration interface as well as a class
diagram showing the data model. It was discussed that the data model for
the BDXL administration API may need to be developed in parallel to the
API if special functions such as batch updating ( grouping participants
with services) need to be supported. Diagrams used for discussions:
https://lists.oasis-open.org/archives/bdxr/202007/msg00017.html . Discussed
whether NAPTR records other than U -flag records are allowed in BDXL
1.0, and whether redirect type NAPTR records can be used as a strategy.
Agreed that we need to advance further with the updated BDXL specification
before moving forward with the API. It was agreed at the August 12 TC meeting
that the introductory sentence in section 2.2 (normative), which states
that Because the goal is to find URLs, the NAPTR RR with U value
in its Flags field (U-NAPTR) narrows the scope of U-NAPTR records in
the specification to those with U -flags, and that U-NAPTR elsewhere
in the specification consequently refers to only those NAPTR records with
U -flags. BDXL
1.1 Starter
document received from OASIS:
https://lists.oasis-open.org/archives/bdxr/202002/msg00015.html Discussed
that the hostname to look up the NAPTR record (commonly done as BASE32([SHA256
hash of participant ID]) and B-[MD5 hash of participant ID] ) should
be standardized. Federated
SML Agreed
to add a section about BDXL network federation to BDXL 1.1. Both Peppol
and the Business Payment Coalition are working towards federated BDXL designs. BPC
rationale is to create competition among several BDXL service providers,
allowing network participants to freely choose among available services.
All BDXL services will offer similar and compatible services. Requirements:
https://lists.oasis-open.org/archives/bdxr/202006/msg00003.html Peppol
is looking at delegating control of different participant identifier schemes
to different SML services, as well as possibly separating groups of participants
based on their ID. There would be an algorithm that enables APs to locate
the appropriate SML service based on the calculation of the participant
identifier. Part of the rationale is that the transactional footprint on
the current SML has increased with the addition of DNSSEC, and grouping
participants into different SML services is a strategy for distributing
the load. Discussion
paper for multiple registration services with only one DNS provider:
https://lists.oasis-open.org/archives/bdxr/202006/msg00003.html Discussed
that in DNS, zone changes are replicated from primary DNS to secondary
DNS services through zone transfers and that the update of primary DNS
services can be done using DNS Update:
https://tools.ietf.org/html/rfc2136 Sander
and Kenneth had a meeting to come up with a proposal for an architectural
drawing of a federated BDXL model within the complete 4-corner network.
The outcome is shared here:
https://lists.oasis-open.org/archives/bdxr/202007/msg00010.html Discussed
that the BDXL specification could/should hold information about the current
registrar service of a given participant, so that BDXL and registrar services
can prevent unauthorized updates of participant identifiers registered
through a different registrar service. Discussed
to include a non-normative section describing different network policies
and approached to KYC and participant registration. Kenneth
will begin drafting an introduction for BDXL 1.1. TC
conference call schedule Face-to-face
meeting Should
we schedule online work sessions to replace the face-to-face meeting? Call
schedule 2021-09-07/2021-09-08 -
Pacific: 18:00MSP/01:00Europe/19:00Ottawa/23:00UTC/09:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe 2021-09-14/2021-09-15 -
Pacific: 18:00MSP/01:00Europe/19:00Ottawa/23:00UTC/09:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe 2021-09-21/2021-09-22 -
Pacific: 18:00MSP/01:00Europe/19:00Ottawa/23:00UTC/09:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe 2021-09-28/2021-09-29 -
Pacific: 18:00MSP/01:00Europe/19:00Ottawa/23:00UTC/09:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe Other
business As
comes forward [attachment "bdx-as4-v1.0-csd01-cert-codes.docx"
deleted by Levine Naidoo/Australia/IBM] --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php Attachment: bdx-as4-v1.0-csd01-cert-codes-LXN.docx Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document