三分一技術士事務所

Visits: 129

Open PEPPOLのeDelivery関連資料は、OpenPEPPOL eDEC Specificationのページに記載。
AS4 Profileに関しては、OpenPEPPOLは、CEF eDeliveryが規定している仕様の一部を採用して運営している。

Open PEPPOLのeDelivery AS4 Profile仕様は、こちらのページ。
CENのeDelivery AS4 Profile仕様は、eDelivery AS4 – 1.15のページ。

Open PEPPOLは、2021年3月時点では、eDelivery AS4 – 1.14を使用しているが、仕様の確認は、eDelivery AS4 – 1.15を参照して調査した。
セキュリティ関連の規定がOpen PEPPOLの文書には詳細が記載されていないため、以下にeDelivery AS4 – 1.15を抄訳する。(Part 2)

4.1. ４コーナー トポロジー

4.1.1. 導入

OASIS ebMS3およびAS4仕様は、2つのメッセージサービスハンドラ間のポイントツーポイントメッセージ交換の仕様。ただし、eDelivery AS4は、メッセージが他の関係者を代行するアクセスポイントによって交換される状況でも使用される。このいわゆる4コーナートポロジーでは、エンドツーエンドの観点から、メッセージ交換に関与するのは2人ではなく4人。 2つの組織は、最初の送信者と最終的な受信者です。他の2つの組織は、元の送信者から最終的な受信者にメッセージをルーティングするアクセスポイントと、応答メッセージを逆ルーティングするアクセスポイントです。 4つのパーティは、Cnラベルを使用して参照される。ここで、Cは「コーナー」を表し、nは1から4までの数字の1つ。

• C1は元の送信者
• C2は、C1を代行してメッセージを送信するアクセスポイント
• C3は、C4に代行してメッセージを受信するアクセスポイント
• C4が最後の受信者

４コーナートポロジーのプロファイル拡張は、アクセスポイントを使用して組織を相互接続するための一般的なソリューションとしてeDeliveryAS4の使用をサポートする。 ４コーナー トポロジーは通常、アクセスポイントがメッセージング ブリッジパターンに従って異種メッセージング ドメインを相互接続する状況で使用される。

• C2は、C1-C2メッセージ交換の受信者と消費者であり、C2-C3メッセージ交換の生産者かつ送信者
• C3は、C2-C3メッセージ交換の受信者と消費者であり、C3-C4メッセージ交換の生産者かつ送信者

ただし、このプロファイル拡張は、メッセージング ブリッジ パターンを含まない、個別の生産者コンポーネントと消費者コンポーネントを識別するためにも使用できる。共通プロファイルはC2-C3交換に適用されるため、交換には、イニシエーターとしてのC2からレスポンダーとしてのC3へのAS4プッシュが含まれる。 C1-C2とC3-C4の間の交換では、AS4を使用する必要はなく、この仕様の範囲外。統合（ストア アンド フォワード、メールボックスなど）に応じて、C3からC4への転送はC3またはC4によって開始される場合がある。

4.1.2.アドレス指定、パーティID、およびトラッキングID

共通プロファイルのこの拡張機能は、4コーナーメッセージ交換でのeDelivery AS4を使用を規定する。 ebMS3メッセージヘッダーの使用規則と、対応する処理モードパラメーターの構成を定義する。
メッセージパッケージの場合、このプロファイル拡張は、AS4メッセージヘッダーのいくつかの要素と全体的なメッセージ構造の値を制約する。 AS4がエンド エンティティ間のポイント ツー ポイント通信に使用されるシナリオでは、eb:UserMessage/eb:PartyInfoのeb:Fromヘッダーとeb:Toヘッダーは、それぞれ送信者と受信者を識別する。 4コーナーモデルでは、AS4メッセージの送信者と受信者は、外側のコーナー組織（C1、C4）ではなく、内側のコーナー アクセスポイント（C2、C3）。変更されていないAS4メッセージング実装の使用を容易にし、AS4メッセージ サービス ハンドラの設定を簡素化するために、eb:From/eb:PartyIdおよびeb:To/eb:PartyIdは内側のコーナー アクセスポイントを識別しなければならない（MUST）。
受信したメッセージをルーティングできるようにするには、受信側のアクセスポイント（C3）が最終的な受信者（C4）を判別できる必要がある。この情報は通常、構造化されたペイロードで利用できる。ただし、構造化ペイロードからの情報を使用することは、ペイロードが基づいているスキーマを理解していることを前提としている。アクセスポイントが任意のタイプのペイロードを処理できるようにするには、特定のスキーマに依存しないメカニズムを採用することが望ましい。さらに、状況によっては、構造化されていないデータまたは暗号化されたデータをルーティングする必要がある場合があう。したがって、このプロファイル拡張では、ebMS3プロパティメカニズムを使用してC1とC4を識別する。プロパティメカニズムにより、AS4メッセージで任意のプロパティと値のペアを使用でき、ペイロードの形式や構造に依存しない。
４コーナートポロジーで使用する場合：

• originalSenderという名前のプロパティは、元の送信者（C1）組織を識別するメッセージに追加する必要がある
• 最終受信者（C4）組織を識別するメッセージにfinalRecipientという名前のプロパティを追加する必要がある

eb:From/eb:PartyIdおよびeb:To/eb:PartyIdヘッダーと同様に、type属性をこれらの2つのプロパティとともに使用して、パーティIDタイプを分類できる（MAY）。アドレス指定の識別子システムおよびフォーマットとして、ISO6523に登録されている組織タイプにはISO6523コードを使用する必要があり、[eDelivery-EBCORE]で指定されているようにebCore組織IDフォーマットを使用する必要がある。

このプロファイルは、追加のオプションの3番目のプロパティを定義する。

• ４コーナーの交換でメッセージのエンドツーエンドの追跡を可能にする識別子（任意の文字列形式）を含めるために、trackingIdentifierという名前のプロパティをメッセージに追加できる（MAY）。 その値は、AS4メッセージが関連するC1からC2へのメッセージの識別子の値に設定される場合がある。 これにより、メッセージの追跡と追跡が可能になる。

ebMS3メッセージプロパティを使用する主な利点は、メッセージペイロードに制約が課されないことだ。 非構造化、バイナリ、または暗号化されている場合でも、任意のペイロード、またはペイロードの組み合わせを転送、ルーティング、および転送することができる。

eDelivery AS4の4コーナートポロジプロファイル拡張を使用する場合：

• ４コーナーのプロパティの値は、C2 AS4MSHへの送信時に生産者が設定する必要がある
• ４コーナーのプロパティの使用は、C2 AS4MSHおよびC3AS4MSHのPモード構成と一致している必要がある
• 受信者C3 AS4 MSHは、メッセージ配信にこれらのプロパティとその値に関する情報を含める必要があり、finalRecipientプロパティでC4として識別される組織を使用する必要がある

4.1.5. 否認防止に関する注記

共通プロファイルで指定されたWS-SecurityでのXML署名の使用は、メッセージ交換レベルでの送信元否認防止（Non Repudiation of Origin　NRO）を提供する。 ４コーナートポロジー拡張機能を使用する場合、発信元はAS4送信側C2であると理解されます。 C1のコンテンツ コミットメントを提供するエンド ツー エンドの送信元否認防止（Non Repudiation of Origin　NRO）は、このプロファイル拡張の範囲外。これは、エンドツーエンドのNROを提供するebMS3パート2「マルチホップ」モジュールとの違いだ。
共通プロファイルで指定されている署名済みのAS4否認防止を使用すると、メッセージ交換レベルでの受領否認防止（Non Repudiation of Receipt　NRR）が提供される。 ４コーナートポロジー拡張機能を使用する場合、受信者はAS4受信者C3であると理解される。 C4のコンテンツ コミットメントを提供するエンドツーエンドの受領否認防止（Non Repudiation of Receipt　NRR）は、このプロファイル拡張の範囲外。これは、エンドツーエンドのNRRを提供するebMS3パート2「マルチホップ」モジュールとの違いだ。
このトピックの詳細については、セキュリティ管理策ガイダンス文書[SECCONTROLS]を参照。

4.2 標準業務文書ヘッダー（SBDH）

4.2.1. 導入

eDelivery AS4共通プロファイルは、UN/CEFACT標準業務文書ヘッダー（Standard Business Document Header）[SBDH]と組み合わせて使用できる。 SBDHは、送信者と受信者の識別、ペイロードのタイプと業務スコープ、業務プロセス、業務ランザクション、契約、業務サービス品質などの一般的なメッセージメタデータをエンコードする標準のXML形式。 SBDHはさまざまな分野で広く採用されている。
AS4と組み合わせて使用する場合、SBDHは次の2つの方法で使用できる。

• スタンドアロンのXML文書として、AS4メッセージ ペイロード パーツとしてパッケージ化され、他の業務コンテンツ パーツとは分離され、統合されていない
• XML業務ペイロード部分の統合部分として

4.2.2. 独立したSBDHインスタンスの使用

独立したXML文書トとして使用する場合、SBDHは特殊なXMLペイロードとして機能し、一種の内部ヘッダーと見なすことができる。他のコンテンツ パーツは、スタンドアロンSBDHパーツで使用するために変更（base64エンコードなど）する必要はなく、追加の個別のメッセージ ペイロード パーツとして交換される。
独立したSBDHは、非XML文書と組み合わせると最も便利だ。この場合、SBDHとペイロードは異なるコンテンツタイプを持っているため、別々のMIME部分にある必要がある。SBDHはXMLであり、ペイロードは非XMLである。非XML業務ペイロードの使用例は、ETSIASiCコンテナ仕様[ASiC]です。 ASiCは非XMLファイル形式であり、MIMEコンテンツタイプはapplication/vnd.etsi.asic-e + zipである。
他のAS4ペイロード部分と同様に、SBDHペイロード部分と追加のメッセージ部分はebMS eb:UserMessageヘッダーから参照する必要がある。 eb:UserMessageヘッダーは、eb:PayloadInfoセクションのコンテンツID URI [RFC2392]を使用して、参照しているMIME部分と同じメッセージ内の他のMIME部分を参照する。 SBDHは、sh:Manifest要素を使用して追加のメッセージ部分を参照する。

4.2.5. SBDHヘッダーを使用したAS4およびXMLペイロード

SBDHをスタンドアロンで使用する代わりに、SBDHをXML業務文書の不可欠な部分にすることもできる。 eDelivery共通プロファイルと一緒に使用すると、SBDH部分を含むこの業務文書は、単一のMIME部分にパッケージ化される。実装者が統合パッケージング アプローチ（XML文書の一部としてのSBDH）または非統合アプローチ（独立したSBDH）を選択する理由は様々。次の議論は統合されたアプローチを支持する：

• SDBHがXMLインスタンス文書の不可欠な部分である場合、文書を高レベルで解析でき、他の情報を考慮せずにルーティングと処理の決定を簡単に行うことができる
• SBDHが別の本体部分に含まれている場合、メッセージがバックエンドアプリケーションに配信されると、2つの本体部分間のリンクが失われ、ルーティング/処理機能がより複雑になる可能性がある

添付ファイルを参照しないXML業務文書の一部であるSBDHには、sh:Manifest要素がない。

4.2.6. ４コーナー トポロジーでのSBDHの使用

SBDHプロファイル拡張は、４コーナートポロジー拡張プロファイルと組み合わせて使用できる。 フォーコーナー コンテキストで、SBDHが「エンドツーエンド」交換に関連する情報のコンテナとして使用される場合、SBDHレベルのsh:SenderはC1の元の送信者に対応し、sh:Receiverは最終的な受信者C4に対応する。 この状況では、SBDHコンテンツの値を使用して、４コーナートポロジー拡張プロファイルで指定されたAS4メッセージプロパティの値を入力し、送信AS4 MSHへの送信時に設定できる。 消費者は、配信されるメッセージについて、AS4 ４コーナー メッセージ プロパティの値が対応するSBDH値の値と一致することを検証する必要がある。

AS4 Header	SBDH
//eb:Messaging[1]/ eb:UserMessage[1]/ eb:MessageProperties/ eb:Property[@name=”originalSender”]/ text()	//sh:StandardBusinessDocumentHeader/ sh:Sender/ sh:Identifier/ text()
//eb:Messaging[1]/ eb:UserMessage[1]/ eb:MessageProperties/ eb:Property[@name=”originalSender”]/ @type	//sh:StandardBusinessDocumentHeader/ sh:Sender/ sh:Identifier/ @Authority
//eb:Messaging[1]/ eb:UserMessage[1]/ eb:MessageProperties/ eb:Property[@name=”finalRecipient”]/ text()	//sh:StandardBusinessDocumentHeader/ sh:Receiver/ sh:Identifier/ text()
//eb:Messaging[1]/ eb:UserMessage[1]/ eb:MessageProperties/ eb:Property[@name=”finalRecipient”]/ @type	//sh:StandardBusinessDocumentHeader/ sh:Receiver/ sh:Identifier/ @Authority

このマッピングは、SBDHが別個のペイロードである状況と、SBDHが主要な業務文書の不可欠な部分である状況の両方に適用される。
元の送信者（C1）から送信アクセスポイント（C2）への交換、および/または受信アクセスポイント（C3）から最終受信者（C4）への交換も、交換をサポートするAS4またはその他のメッセージングプロトコルに基づいている場合 マルチパート/関連MIMEコンテナ（ebMS2やAS2など）を使用する複数のペイロードの場合、SBDHパートを含むすべてのメッセージペイロードと、Content-IDヘッダーに基づくそれらの間の相互参照を情報を失うことなく転送できる。
SBDHプロファイル拡張を４コーナートポロジー拡張プロファイルと組み合わせて使用する必要はないことに注意。 ポイントツーポイント交換でも使用できる。

4.2.7. AS4ヘッダーとSBDHの比較

AS4ヘッダーは、ebMS3 SOAPメッセージの一部であるebMS3eb:Messagingヘッダーである。 これはメッセージペイロードではなく、AS4メッセージサービスハンドラーによって処理される。 AS4ユーザーメッセージヘッダーの形式と内容は、以前のebMS2.0標準で定義されたヘッダー構造に似ている。 ヘッダーは次のことを可能にする。

• 配信基準を使用して特定のバックエンドアプリケーションにメッセージをルーティングまたは配信する
• 特定のパートナー、サービス、または業務プロセスとの業務活動を監視する
• AS4ヘッダーのみに基づいて、ペイロードに依存しない方法でメッセージを追跡する

次の表は、AS4メッセージングヘッダーとSBDHの比較を示しており、それらの機能の類似性を示している。

AS4 eb:PartyInfoグループには、eb:From組織とeb:To組織に関する情報が含まれている。 ４コーナー拡張と併用すると、コーナー2と3を識別する。	対応するSBDH要素は、sh:Sender要素とsh:Receiver要素。 ４コーナー拡張と併用すると、コーナー1と4が識別される
AS4 eb:CollaborationInfoグループには、オプションのeb:AgreementRef要素と必須のeb:Service、eb:Action、eb:ConversationId要素が含まれている。	SBDHのオプションのsh:BusinessScopeグループと関連するsh:BusinessScopeスキーマは、同様の目的を持つ要素sh:BusinessServiceNameとsh:ServiceTransactionを提供する。
オプションのeb:MessagePropertiesグループには、一連の任意の名前/値のプロパティが含まれている。	SBDHには、XMLスキーマタイプの置換に基づく同様の拡張メカニズムがある。
AS4 eb:PayloadInfoグループには、すべてのメッセージペイロード部分に関する情報が含まれている。ペイロード自体は、AS4 MIMEメッセージの個別のMIME部分に保存され、href属性を介して参照される。	SBDHでは、sh:Manifestグループが（非XML）添付ファイルに使用される。 SBDH自体は、スタンドアロンで使用することも、標準の業務文書（XMLペイロードなど）の一部として使用することもできる。 AS4の場合と同様に、添付ファイルは個別のMIMEパーツに含めることができる。

AS4ヘッダーはほとんどのSBDH機能を提供するため、多くの場合、SBDHは必要ない。

4.3. ダイナミックレシーバー

4.3.1. 導入

従来のB2Bデータ交換では、当事者は既知の一連の取引相手と対話する。 メッセージングの実装により、ユーザーは、署名証明書や暗号化証明書、エンドポイントURIなど、取引相手とこれらの取引相手のメッセージ交換パラメーターを構成できる。 取引相手が追加または削除されたり、構成パラメーター値が変更されたりすると、利用者はこれらの構成を更新する。
このオプションのプロファイル拡張により、受信メッセージのこの要件が緩和され、受信MSHに登録されておらず、組織識別子と署名証明書が事前に共有されていない送信側組織からユーザーメッセージを受信するように組織がAS4 MSHを設定できるようになる。 送信者と受信者。 組織の認証と承認については、X.509PKIベースのメカニズムを指定する。

4.4. ダイナミックセンダー

4.4.1. 導入

従来のB2Bデータ交換では、当事者は既知の一連の取引相手と対話する。メッセージングの実装により、ユーザーは、署名証明書や暗号化証明書、エンドポイントURIなど、取引相手とこれらの取引相手のメッセージ交換パラメーターを構成できる。利用者は、取引相手が追加または削除されたとき、または取引相手の構成が変更されたときに、これらの構成を更新できる。
このオプションのプロファイル拡張機能により、発信メッセージに対するこの要件が緩和され、組織はAS4 MSHを設定して、事前設定されていない受信者組織にユーザメッセージを送信できる。これらの組織の場合、組織識別子とAS4プロトコルパラメータ（パーティの暗号化証明書やAS4サーバーエンドポイントのアドレスなど）は送信MSHに登録されない。プロファイル拡張は、生産者によって提供された追加のパラメーターを使用してテンプレートをインスタンス化し、検出インフラストラクチャでクエリを使用して取得したデータを使用して、Pモードを動的に作成し、アドホックベースで展開できるメカニズムを提供する。