[Wg-iop] update on eGov test cases
Kyle Meadors
Great progress last week on the eGov 2.0 test cases. Currently, the only sections missing confirmation steps are PKIX (Terry McBride), Attributes (Denny Prvu), Logout Requests/Responses (Fulup Ar Foll) and Security and Encryption Algorithms (John Bradley). A few of these said they would not be able to get to the sections until today due to commitments/travel last week so I hope to see these remaining sections filled in today or tomorrow.
With phase 1 done, we need to move to second phase (due by end of this week, 6/18) of fleshing out the test cases where we instruct the products under test how to go about conducting the testing necessary to verify or not our confirm steps. This involves putting in at a minimum a precondition/prerequisite section describing the current state prior to executing the actions, then sequences or explicit actions to take for the systems-under-test and finally where in the sequence the confirm step(s) are included. You may also want to include a general description, background or scope of test as well to elaborate on what is being done.
If you look at the section Scott Cantor and Jonathan Scudder did, they already include the preconditions and sequences. They are both good examples to follow.
Next, you need to explicitly call out your test case with some type of identification. I renamed all the sections with a prefix of “Section X” where X is a unique number. Then in your section, for each test case – some sections will just have one test case and others will have several – you number your test cases as X.1, X.2, etc. where X is your section number. I took Scott’s first section test cases and did that myself.
Lastly, please keep in mind feasibility of the test cases. That is, can what you want to confirm be done with SPs/IdPs acting “normally” or do we need a unique error generating harness or a special environment to do this? If you are concerned that the test case may not be able to be conducted due to some limitation, let me know. It is possible we may not be able to do all test cases this round because of these restraints but at least Kantara will know the resources necessary for conducting the test case in a future test round.
Kyle Meadors
Drummond Group Inc.
Director of EHR Testing
Principal, Test Process
Calendar: http://tinyurl.com/KyleMeadors-DGI-Calendar
* * * * * * * * * * * * * * * * * * * * * * * *
CONFIDENTIALITY DISCLAIMER
This email, including attachments, is confidential and proprietary. It constitutes exclusive communication solely to the addressee. Any entity other than the intended addressee is prohibited from use of this communication for any purpose. This email, including attachments, may not be distributed, whole or in part.
* * * * * * * * * * * * * * * * * * * * * * * *
Paul Madsen
I noticed that in Jonathan's section 8 on message content, he calls out tests for NameIDPolicy in AuthnRequest and NameID in Response that would duplicate the tests I've listed in Section.
Jonathan's tests for name identifiers are merely part of broader testing for various message parameters. Do people think that name identifiers deserve separate tests?
paul
_______________________________________________ WG-IOP mailing list WG-...@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-iopNo virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.829 / Virus Database: 271.1.1/2932 - Release Date: 06/11/10 14:35:00
Paul Madsen
paul
On 17/06/2010 10:09 AM, Jonathan Scudder wrote:
Hi Paul,
I agree that there is some overlap here. The AuthnRequest test case verifies that the NameIDPolicy element, which is optional in SAML 2.0 but required for eGov 2.0, is supported. Your test cases go further by checking that transient and persistent are both acceptable. Since your tests implicitly confirm the section 8 cases, I suggest that you keep the tests in section 4 and I will remove that test from section 8 (referring to section 4 instead).
On the same topic, can anyone confirm that supporting the inclusion of NameIDPolicy as per chapter 2.5.2.2 of the eGov specification does not mean that this child element has to be present in every AuthnRequest message? I read this as being a mandatory capability rather than a mandatory element.
258 In addition to standard core- and profile-driven requirements, Service Provider implementations MUST259 support the inclusion of at least the following <saml2p:AuthnRequest> child elements and attributes260 (when appropriate)::...267 • <saml2p:NameIDPolicy>
Thanks,-Jonathan
_______________________________________________
WG-eGov mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-egov
--
Jonathan Scudder : ForgeRock AS
e: jonathan...@forgerock.com
t: +47 40246904
w: www.forgerock.com
