OK. I just made a quick search through the TC’s agendas and meeting minutes and didn’t find any references, so probably the question was not raised to the TC again, following the January/February
2015 conversation. I will put it on the agenda for our May 24 meeting. Would you be able to participate?
It’s my understanding that the ProcessList/../Endpoint/Certificate is used for validating the signature of the receiving endpoint (as stated in the spec) by those implementations that I
am aware of. Notwithstanding, I don’t see anything deterring a network from defining a policy requiring endpoints to encrypt payloads (and using the ProcessList/../Endpoint/Certificate or, perhaps more appropriately, an Extension element) to communicate the
decryption key. However, my initial observation is that this might be out of scope for SMP and perhaps should be dealt with on a transport protocol, messaging protocol, and/or payload level. The network could use a payload container (such as the BDE) if encryption
is required. But this probably requires more analysis and discussion by the TC.
Best regards,
Kenneth
From:
Pim van der Eijk <
pvde@sonnenglanz.net>
Date: Monday, May 15, 2017 at 10:05 AM
To: Kenneth Bengtsson <
kbengtsson@efact.pe>, "bdxr@lists.oasis-open.org" <
bdxr@lists.oasis-open.org>
Subject: Re: [bdxr] 60-day public reviews for Service Metadata Publishing and Business Document Metadata Service Location COS01 - end May 14th
Indeed I raised the same question in 2015 and reported that in the 2016 discussion, pointing to that discussion. The 2016 discussion was not on the TC mailing list but on a separate non-public mailing list (e-SENS project), but that was a list in which
several then and currently active TC members participated, including in this discussion.
On 15-05-17 16:45, Kenneth Bengtsson wrote:
Dear Pim
Thank you for your comment to the SMP COS. I will put your observation on the agenda for our next meeting, May 24.
Meanwhile I was looking for the comment from 2016 that you mention, but I haven’t been able to find it in our TC mailing list nor in the TC comment mailing list. Could you forward me the
comment please?
The only thing I have been able to find so far is this conversation from early 2015, where we discussed that the ProcessList/../Endpoint/Certificate is indeed used for validating the signing
certificate (for example, this becomes useful in cases where an out-of-band trust model is not agreed upon in the network):
https://lists.oasis-open.org/archives/bdxr/201502/msg00010.html Best regards,
Kenneth
From:
<
bdxr@lists.oasis-open.org> on behalf of Pim van der Eijk
<
pvde@sonnenglanz.net>
Date: Sunday, May 14, 2017 at 11:07 AM
To: "bdxr@lists.oasis-open.org"
<
bdxr@lists.oasis-open.org>
Subject: Re: [bdxr] 60-day public reviews for Service Metadata Publishing and Business Document Metadata Service Location COS01 - end May 14th
Section 2.3.4.4 of SMP COS states that
ProcessList/../Endpoint/Certificate
is to hold:
the complete [X509v3] signing certificate of the recipient gateway, as a base 64 encoded DER formatted
value.
In July 2016 this was discussed in the e-SENS project where it was commented that
"A CR is needed indeed, either to change the description from "signing cert" to "encryption cert", or to add one more element for the encryption cert"
and that
" a change should be applied to the SMP specification to state that this certificate is to be used for encryption. As the the SMP is about describing of the services a participant provides it does not make sense to include the signing certificate as the
signing needs to be done by the sender of the message, i.e. the user of the services (which is not necessarily included as such in the SMP "
Kind Regards,
Pim
On 15-03-17 15:59, Chet Ensign wrote:
OASIS members and other interested parties,
Members of the OASIS Business Document Exchange (BDXR) TC [1] have recently approved Special Majority Ballots [2] to advance Service Metadata Publishing (SMP) Version 1.0 and Business Document Metadata Service Location Version 1.0 as Candidate
OASIS Standards (COS). The COSs now enter a 60-day public review period in preparation for a member ballot to consider their approval as an OASIS Standards.
Service Metadata Publishing (SMP) Version 1.0
Candidate OASIS Standard 01
09 March 2017
and
Business Document Metadata Service Location Version 1.0
Candidate OASIS Standard 01
09 March 2017
What are the Candidate OASIS Standards and why are they important?
"Service Metadata Publishing" describes a protocol for publishing service metadata within a 4-corner network, where entities exchange business documents through intermediary gateway services.
To successfully send a business document in a 4-corner network, an entity must be able to discover critical metadata about the recipient (endpoint) of the business document, such as types of documents the endpoint is capable of receiving
and methods of transport supported. The recipient makes this metadata available to other entities in the network through a Service Metadata Publisher service.
The COS describes the request/response exchanges between a Service Metadata Publisher and a client wishing to discover endpoint information. A client can either be an end-user business application or a gateway/access point in the 4-corner
network. It also defines the request processing that must happen at the client.
The TC received 5 Statements of Use from Chasquis Consulting, Efact S.A.C., IBM, Norwegian Agency for Public Management and Government (Difi), and ph-peppol-smp-server [3].
"Business Document Metadata Service Location" defines service discovery method values for use in DNS Resource Record service fields. A method is first specified to query and retrieve a URL for metadata services. Two metadata service types
are then defined. Also an auxiliary method pattern for discovering a registration service to enable access to metadata services is described. The methods defined here are instances of the generic pattern defined within IETF RFCs for Dynamic Delegation Discovery
Services (DDDS). This specification therefore defines DDDS applications for metadata and metadata-registration services.
The TC received 3 Statements of Use from Chasquis Consulting, Norwegian Agency for Public Management and Government (Difi), and European Commission Directorate General for Informatics, DG DIGIT [4].
About the TC:
The OASIS BDXR TC advances an open standards framework to support public e-procurement and e-invoicing. The group defines specifications for a lightweight and federated messaging infrastructure that supports a 4-corner model for the secure
and reliable exchange of electronic documents. Wherever possible, the TC specifications are based on profiles of existing standards from OASIS and elsewhere. BDXR TC members also coordinate the submission of new requirements as use cases for expanded functionality.
All those involved in e-procurement and e-invoicing are invited to participate in the BDXR TC, including public and private sector agencies, enterprises, solution providers, consultants, and researchers. E-payment actors including financial
institutions, associations and payment networks should also be represented in this work.
Public Review Period:
The 60-day public review starts 16 March 2017 at 00:00 UTC and ends 14 May 2017 at 23:59 UTC.
This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work.
URIs:
The prose specification document and related files are available here:
- Service Metadata Publishing (SMP) Version 1.0
Editable source (Authoritative):
http://docs.oasis-open.org/bdxr/bdx-smp/v1.0/cos01/bdx-smp-v1.0-cos01.doc HTML:
http://docs.oasis-open.org/bdxr/bdx-smp/v1.0/cos01/bdx-smp-v1.0-cos01.html PDF:
http://docs.oasis-open.org/bdxr/bdx-smp/v1.0/cos01/bdx-smp-v1.0-cos01.pdf XML schemas:
http://docs.oasis-open.org/bdxr/bdx-smp/v1.0/cos01/schemas/ - Business Document Metadata Service Location Version 1.0
Editable source (Authoritative):
http://docs.oasis-open.org/bdxr/BDX-Location/v1.0/cos01/BDX-Location-v1.0-cos01.odt HTML:
http://docs.oasis-open.org/bdxr/BDX-Location/v1.0/cos01/BDX-Location-v1.0-cos01.html PDF:
http://docs.oasis-open.org/bdxr/BDX-Location/v1.0/cos01/BDX-Location-v1.0-cos01.pdf ZIP distribution file (complete):
For your convenience, OASIS provides complete packages of the prose specifications and related files in ZIP distribution files. You can download the ZIP files here:
- Service Metadata Publishing (SMP) V1.0:
http://docs.oasis-open.org/bdxr/bdx-smp/v1.0/cos01/bdx-smp-v1.0-cos01.zip - Business Document Metadata Service Location Version 1.0:
http://docs.oasis-open.org/bdxr/BDX-Location/v1.0/cos01/BDX-Location-v1.0-cos01.zip Additional information about the specification and the BDXR TC may be found at the TC's public home page:
https://www.oasis-open.org/committees/bdxr/ Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility as explained in the instructions located via the button labeled "Send A Comment" at the top of the TC public home page, or directly at:
https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=bdxr Comments submitted by TC non-members for this work and for other work of this TC are publicly archived and can be viewed at:
http://lists.oasis-open.org/archives/bdxr-comment/ All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with these public reviews of
“Service Metadata Publishing (SMP) Version 1.0" and "Business Document Metadata Service Location Version 1.0,” we call your attention to the OASIS IPR Policy [5] applicable especially [6] to the work of this technical committee. All members of the TC should
be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification.
OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work.
==============
[1] OASIS Business Document Exchange (BDXR) TC
http://www.oasis-open.org/committees/bdxr/ [2] Special Majority Vote ballots
Service Metadata Publishing (SMP) V1.0:
https://www.oasis-open.org/committees/ballot.php?id=3046 Business Document Metadata Service Location V1.0:
https://www.oasis-open.org/committees/ballot.php?id=3047 [3] Statements of Use for Service Metadata Publishing (SMP) V1.0:
- Chasquis Consulting:
https://lists.oasis-open.org/archives/bdxr/201610/msg00007.html - Efact S.A.C.:
https://lists.oasis-open.org/archives/bdxr/201609/msg00008.html - IBM:
https://lists.oasis-open.org/archives/bdxr-comment/201611/msg00000.html - Norwegian Agency for Public Management and Government (Difi):
https://lists.oasis-open.org/archives/bdxr/201611/msg00003.html , and
- ph-peppol-smp-server:
https://lists.oasis-open.org/archives/bdxr-comment/201609/msg00001.html [4] Statements of Use for Business Document Metadata Service Location Version 1.0:
- Chasquis Consulting:
https://lists.oasis-open.org/archives/bdxr/201702/msg00002.html - Norwegian Agency for Public Management and Government (Difi):// lists.oasis-open.org/archives/bdxr/201611/msg00004.html , and
- European Commission Directorate General for Informatics, DG DIGIT:
https://lists.oasis-open.org/archives/bdxr-comment/201702/msg00002.html [5]
http://www.oasis-open.org/policies-guidelines/ipr [6]
http://www.oasis-open.org/committees/bdxr/ipr.php https://www.oasis-open.org/policies-guidelines/ipr#s10.3 Non-Assertion Mode
--
/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org Primary: +1 973-996-2298
Mobile: +1 201-341-1393