|
In the Action 4, Assumption: Alpha is planning to use the
same certificate with Bravo and Charley for signing the message. With CEM, Alpha would be able to
communicate with Bravo, the effective date/time of new certificate in CEM and
things happen automatically. However, in the case of Charley it being manual
there may be timing issue. Adding some additional scenarios that actually
handles the “Certificate Change” itself would be helpful.
Especially, if there is a potential need for a product to maintain two
certificates at the same time until both TPs has been migrated to new
certificate. ** This should not be an issue when Alpha
maintains different certificate to sign the message when sending message to
different TPs. From: Kyle Meadors
[mailto:kyle@xxxxxxxxxxxxxxxxx] Since there appears to be consensus in using
EDIINT–Features header to announce feature support in trading partner, I
have put together the following scenarios. Are these accurate? I have also
included the EDIINT–Features draft which was issued last year to IETF.
Does it convey all information needed for a robust implementation? Actors: Company Alpha and Trading Partners Bravo and Charley Initial Condition: Alpha has trading relationship with Bravo
and both are using AS2–Version: 1.1 products. TP Charley is schedule to
be setup with Alpha. Action 1: Alpha upgrades product to AS2–Version: 1.2
using EDIINT–Features. It supports feature CEM. Expected Outcome–1: All messages coming out of Alpha
contain EDIINT–Features header and AS2–Version: 1.2. Expected Outcome–2: Bravo ignores and does NOT fail
Alpha’s messages and processes them “normally”. Alpha does
NOT send CEM messages to Bravo because it does not detect EDIINT–Features
support for CEM. Action 2: Bravo upgrades product to AS2–Version: 1.2
using EDIINT–Features. It supports features CEM and MA. Expected Outcome–1: All messages coming out of Bravo
contain EDIINT–Features header and AS2–Version: 1.2. Expected Outcome–2: Both Alpha and Bravo recognize
each other’s support of CEM through EDIINT–Features header, and
Bravo recognizes Alpha does NOT support MA. Action 3: Alpha onramps Charley as a trading partner. Expected Outcome–1: Certificates for both Alpha and
Charley MUST be exchanged out–of–band Expected Outcome–2: After trading begins, Alpha
recognizes Charley does NOT support CEM through its messages. Action 4: Alpha issues new certificates. Expected Outcome–1: Alpha sends new certificates
through CEM to Bravo. Bravo follows CEM procedure and upgrades certificates. Expected Outcome–2: Alpha exchanges new certificates
with Charley out–of–band. Charley upgrades new certificates and
notifies Alpha of upgrade. Kyle Meadors Principal, Test Process Drummond Group Inc. 615.212.0826 --
|