Views: 104

以降は、PEPPOL AS4 Profileの抄訳

1.説明

この文書では、PEPPOLネットワークでAS4を実装する方法について説明。
AS4の実装は、[CEFeDeliveryAS4]（CEF eDelivery AS4プロファイルv1.14）にしたがわなければならないだけでなく、CEF仕様で規定されていないかオプション仕様ででPEPPOLネットワークでも使用されていない機能と属性をさらに定義および制限するこの文書で説明する仕様に従う必要がある。
すなわち、AS4はPEPPOLネットワークで使用され、AS4メッセージレベルでの署名と暗号化にPEPPOL PKIを使用し、動的検出にSMP/SMLを使用して、４コーナートポロジーのコーナー2とコーナー3の間で非同期メッセージを送信する。

2.変更履歴

省略

3.基本仕様

CEF eDelivery AS42.1に関連する。
以下の表には、[CEFeDeliveryAS4]の機能と比較した、OpenPEPPOL AS4仕様で変更した機能の概要を示す。

表記

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [RFC2119].
RFC2119の翻訳ページはこちらをクリック

4.OpenPEPPOLでの実装

4.1. 交換パターン

CEF eDelivery AS4 3.2.1、3.2.2、および3.4.2に関連。
一方向/プッシュは、OpenPEPPOLで現在サポートされている唯一の交換パターンであり、PEPPOLネットワーク内のすべての送信に使用する必要がある。
一方向/プルは、[CEFeDeliveryAS4]のオプションのMEP。 OpenPEPPOLには、特定のMEPでカバーされる要件がないため、一方向/プルMEPは使用しない。
[CEFeDeliveryAS4]に従ってサポートするには、双方向/プッシュアンドプッシュが必須ですが、PEPPOLネットワークでは使用しない。 （これにより、eb:RefToMessageIdが使用されなくなる。）
双方向/同期は、PEPPOLネットワークでの非同期送信のために除外され、PEPPOLネットワークでは使用されない。

4.2. トランスポートレベルセキュリティ（TLS）の構成

CEF eDelivery AS43.2.6および3.4.5に関連。
PEPPOLネットワークの一部であるアクセスポイントは、[CEFeDeliveryAS4]で説明されているように、メッセージを送信する前にIPおよびポートに関連する情報を交換しない。
PEPPOLネットワークでは、アクセスポイントは次のように構成する必要がある。
受信アクセスポイントは、CEF eDelivery AS4の3.2.6節に従ってTLSをサポートする必要がある。 TLS v1.2より新しいバージョンは、TLSハンドシェイクを介した相互合意に基づいて使用される場合がある。
TLSにポート443を使用することを強く勧める。 これが不可能な場合、受信アクセスポイントは44300〜44399の範囲のポートを使用する必要がある。
アクセスポイントの送信は、ポート443および44300-44399へのアウトバウンド送信を許可するだけで済む。
TLSは、トランスポートセキュリティのためにPEPPOLポリシーに準拠した有効な証明書を使用する必要がある。

4.3. 合意(Agreement)

CEF eDelivery AS4 3.2.2に関連。
PEPPOL eDeliveryネットワーク内の2つのアクセスポイント間のメッセージ交換は[TIA-AP-PROV]に基づいているため、メッセージ交換を管理する業務契約を示すために使用されるPMode.Agreementパラメーターの値はurn:fdc:peppol.eu:2017:agreements:tia:ap_provider（type属性なし）である必要がある。契約への参照は、ebMSメッセージングヘッダーのeb3:AgreementRef要素に含まれている。
eb3:AgreementRef要素には、PMode.IDを含めるために使用できるオプションの属性pmodeも含まれている。 アクセスポイントはメッセージの受信に1つの汎用Pモードのみを使用する可能性があるため、この属性は使用しないこと。

4.4. 受信がサービス提供されていないときのフィードバック

アクセスポイントは業務文書を受信すると、メッセージを配信できるようにするために、アドレス指定された参加者に特定の文書タイプIDとプロセスIDのサービスを提供するかどうかを確認する必要がある(SHOULD)。 MSHがebMSメッセージの処理中にユーザーメッセージのペイロードのカスタム検証を実行できる場合は、アクセスポイントに宛先、文書トタイプID、およびプロセスIDのチェックを含めることを推奨する。 アドレス指定された参加者がアクセスポイントによって特定の文書タイプおよびプロセスに対してサービスを受け付けていない場合、ebMSエラーを生成して返送する必要がある。
生成されたエラーのerrorCode属性はEBMS:0004（その他のエラー）に設定する必要があり、その重大度属性を失敗に設定する必要がある。 さらに、errorDetail属性の値は、PEPPOL:NOT_SERVICEDである必要がある。これは、アドレス指定された参加者がアクセスポイントによってサービスされていないことを示す。

4.5. 組織識別子

CEF eDelivery AS4 3.4.1及び4.1.2に関連。

trackingIdentifierは、OpenPEPPOLによって指定されていないため、使用してはならない(MUST NOT)。

4.6. サービス, アクション及びロール

CEF eDelivery AS4 3.4.4に関連。
業務文書トを送信する場合、アクセスポイントはPMode[1].BusinessInfo.Serviceの値を業務文書に指定されているPEPPOLプロセス識別子の値に設定しなければならない(MUST)。 PMode[1].BusinessInfo.Service.typeは、業務文書に指定されているPEPPOLプロセス識別子スキーマに設定しなければならない（指定されていない場合のデフォルトはcenbii-procid-ubl）。 スキームとプロセス識別子の値は、URLパーセントエンコーディングを使用してはならない（SHALL NOT）。
PMode[1].BusinessInfo.Actionは、業務文書用に定義された業務文書のエンコードされた文書タイプ識別子に設定しなければならない(MUST)（文書タイプ識別子スキームが指定されていない場合、デフォルトは、busdox-docid-qns）。 文書タイプ識別子は、[PEPPOL-ID-POL]で指定されているようにフォーマットしなければならない(MUST)。

4.7. PEPPOL PKIの使用

CEF eDelivery AS43.2.6及び3.4.5に関連。
PEPPOLネットワーク内のすべての通信は、PEPPOL　PKIを使用する。 証明書は、SMPからフェッチするときに検証する必要がある。 OpenPEPPOLによって発行されていない証明書は使用してはならない。

4.8. デフォルトのMPCの使用

[ebMS3CORE]で定義されているメッセージパーティションチャネル機能は、PEPPOLeDeliveryネットワークのアクセスポイント間のメッセージ交換では必要としない。 したがって、デフォルトのMPCが使用される。つまり、PMode[1].BusinessInfo.MPCは次のように設定する必要がある。
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC
[i]デフォルトのMPCが使用されるため、ebMSメッセージヘッダーでeb3:UserMessage/@mpc属性を省略してもよい(MAY)。

4.9. SBDHの使用

CEF eDelivery AS44.2に関連。
PEPPOLネットワーク内のすべての送信は、[PEPPOL-Envelope]に従ってSBDHを使用して統合された部分としてコンテンツをパッケージ化する必要があり、SBDHは必須であるため、4.2.7をスコープ外とする。
[CEFeDeliveryAS4]で説明されているスタンドアロンSBDHはサポートされていないため、使用しない。4.2.2、4.2.3、4.2.4は、範囲外。
PEPPOLネットワークでの送信には、[CEFeDeliveryAS4] 4.2.1、4.2.5、4.2.6が関連しており、originalSenderおよびfinalRecipientの使用も含まれる。
業務メッセージを含むSBDHは、AS4ヘッダーを含むMIME添付ファイルに続く最初のMIME添付ファイルで見つけなければならない(MUST)。

4.10. メッセージパッケージ

CEF eDelivery AS43.4.6に関連。
[ebMS3CORE]の5章で定義されているように、ebMSユーザーメッセージのペイロードは、SOAP本文または個別のMIME添付ファイルのいずれかに含まれている可能性がある。 ただし、このプロファイルでは、添付ファイルにパッケージ化されたペイロードにのみ適用されるAS4圧縮機能（以下を参照）を使用するため、アクセスポイントにはすべてのペイロードをMIME添付ファイルとして含まなければならない(MUST)。
[i]大きなメッセージを送信する場合、アクセスポイントはhttpチャンク転送エンコーディングを使用して、より合理化された処理を有効にすることができる。 [RFC7230]の4.1節で指定されているように、アクセスポイントはメッセージを受信するときにこのエンコーディングをサポートする必要がある。
[AS4-Profile]の5.1.9節で説明されている「Content-Disposition」MIMEヘッダーは、添付されたペイロードのファイル名を交換するために使用してはならない(SHALL NOT)。 MIMEヘッダーの削除をサポートしていないAS4実装は、ファイル名としてpayload.xmlを使用しなければならない(MUST)。

5. P-Modeパラメタ

こちらをクリック。

6. AS4に関連しない事柄

こちらをクリック。

7.適合性

こちらをクリック。