Minutes of Atlantic BDXR TC call 04 June 2025 15:00UTC
http://www.timeanddate.com/worldclock/fixedtime.html?iso=2025-06-04T15:00:00
Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe
Participation
Todd Albers
Kenneth Bengtsson (chair)
Kees Duvekot
Pim van der Eijk
Sander Fieten (chair)
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
Review of Atlantic call minutes
Minutes available under "Discussion" in the new Community Workspace:
https://groups.oasis-open.org/communities/community-home/digestviewer?communitykey=43073186-e469-4754-9b05-018dc7d3ef8b
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):
- Kenneth Bengtsson
- Kees Duvekot
- Sander Fieten
Members gaining voting status after this meeting:
- Todd Albers
Members losing voting status after this meeting:
-
TC Vitality
The TC must next appoint or reappoint chair(s) in January 2027.
Next TC vitality check must be made in January 2029.
BDXL federation and update API
The TC discussed BDXL federation and operation based on input provided from Sander (Sander will share PPT with mailing list). Discussed to segregate the duties of "Operator" and "Registrar". Agreed to continue discussion next meeting. Sander will prepare a diagram showing roles and responsibilities.
AS4 Profile for Four-corner Networks
Agreed to move forward as a candidate OASIS Standard. Statements of Use?
SMP 2.1
New input and requirements:
- Authentication feature using the HTTP authorization header, possibly MTLS
o Erlend will write a draft
- "Process Group Lookup"
o Sander will highlight relevant sections in spec
- Technical contact information for SMP operator
o Sander will highlight relevant sections in spec
- ActivationDate and ExpirationDate: some users are not aware that xsd:date has an optional time zone component. This can be clarified in the next version of the spec.
- Request from user: Add a query parameter to the service metadata to request only the service metadata of a specific service in a specific process. Does it add true value and shall we include it?
A starter document for SMP 2.1 has been provided here: https://lists.oasis-open.org/archives/bdxr/202302/msg00005.html.
June 4 discussion:
SMP requirements
Client authentication
More a question on whether this is seen at other projects and what kind of authentication is used.
TLS client certs and HTTP Basic auth are common solution, but also OAuth2 CC tokens could be used. Current text in spec (§5.6.1) is very open ended and could be refined by adding section on client side authentication.
However there is/can be quite a difference in how mTLS is handled versus authentication included in the http request. With mTLS the connection can already be rejected during the TLS handshake preventing the SMP server to respond. This difference should be taken into consideration when writing the text on authentication.
Projects are looking at this currently and would prefer have guidance from TC asap.
SMP use not involving BDXL
SMP can already be used without using dynamic discovery, for example using one fixed SMP server. Question is whether the specification should include conformance clauses for this scenario as well as using the dynamic discovery. This could also be topic to be included in BDXL 1.1 to better specify how a DNS name should be generated from a ParticipantID
Application specific certs
This is already possible but it may not be clear from the spec because the Certificate class is part of the Endpoint. Usage to provide app specific or C4 certs can be documented in a CN or by adding a note to the spec.
SMP info on senders
This feature is mostly requested if the network does not have a PKI where the sender can be verified through the PKI, e.g. a "generic" CA issues the certs. By looking up the sender in the SMP the certificate could be validated.
Currently this could be implemented by "hacking" the SMP by adding the sender with an Endpoint that contains their certificate or add it as Extension.
Adding information on senders in the specification directly would require a change in the data model. Given that in many networks senders are already registered in the SMP anyway because they need to be able to receive response documents it is agreed this is not something the TC considers to standardise.
BDXL
Requirement gathering for BDXL 1.1 still in progress. Notes available here: https://lists.oasis-open.org/archives/bdxr/202205/msg00003.html
Sander has created a set of draft definitions for expanding on the BDXL terminology and for better describing BDXL in a four-corner context: https://lists.oasis-open.org/archives/bdxr/202401/msg00003.html
- The definitions were reviewed by the February 6 Pacific call without comments.
TC conference call schedule
Agreed to temporarily suspend the Pacific calls while we have no participants from the Pacific region. Pacific calls will be reinstated upon request from any TC member.
Call schedule
2025-09-02/2025-09-03
- Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe
2025-10-07/2025-10-08
- Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe
2025-11-04/2025-11-05
- Atlantic: 10:00MSP/11:00Ottawa/16:00UTC/17:00Europe
2025-12-02/2025-12-03
- Atlantic: 10:00MSP/11:00Ottawa/16:00UTC/17:00Europe
Other business
None
Este correo electrónico y cualquier archivo transmitido con él son propiedad de Efact S.A.C., contiene información confidencial, y están destinados exclusivamente al uso de la persona o entidad a la que van dirigidas. Si usted no es el destinatario señalado, no puede difundir y distribuir o copiar este e-mail. Por favor notifique inmediatamente al remitente por correo electrónico si usted ha recibido este correo electrónico por error, y eliminar este correo electrónico de su sistema. Si usted no es el destinatario, se le notifica que revelar, copiar, distribuir o tomar cualquier acción basada en el contenido de esta información está estrictamente prohibida.
This email and any files transmitted with it are the properties of Efact S.A.C., contains confidential information, and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you may not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake, and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.