[Wg-iop] eGov2 Test Cases - Next To Last Draft

3 views
Skip to first unread message

Kyle Meadors

unread,
Jun 28, 2010, 12:04:26 PM6/28/10
to wg-...@kantarainitiative.org, wg-iop

I have done some high level editing of the eGov test cases. Several of the test cases were removed as they were already covered in the current test plan. Still, very grateful for those of you who did do the work but got the test cases removed. It was still good due diligence on our part to do it. And, if you feel your “cut” test case was not properly tested in the current test plan, please share why on today’s call.

 

On today’s call, we will walk through each test case and confirm they are IN or OUT or maybe just DEFERRED. We can also take time to make small adjustments but we don’t have time for lengthy discussion.

 

Also, I recommend we defer the IdP Proxying test cases which Bob Sunday did (and were quite good) as we never got test cases for Holder of the Key and thus can not fully test for eGov2-Full conformance. I recommend we put the proxying test cases in next year along with Holder of the Key so we can certify eGov2-Full.

 

I am looking for guidance on if some of these test cases can be successfully tested by just pairing up or testing against a single implementation. That is, it is NOT an interoperability test case where you need to verify the exchange points with all partners but a pure conformance/functionality test case that can be fully tested by just having a single partner/reference implementation. Error tests are typically in this latter category, but I am wondering if some of the metadata test cases can be tested with just a partner. The obvious benefit is it a single partner/implementation test is much faster, but we can’t do it if truly need full-matrix testing. This is a full-matrix interoperability test event.

 

Finally, we have to verify what we have is “feasible” to test. If the test case needs some extra test tools, especially in the error testing realm, then we may have to defer the test case until next year. Ultimately, that would be a decision of IOP WG and IRB but we can indicate where support is needed and they can decide where to try and test it this year.

 

http://kantarainitiative.org/confluence/display/eGov/Test+Cases

 

Kyle Meadors

Drummond Group Inc.

Director of EHR Testing

Principal, Test Process

817-709-1627

ky...@drummondgroup.com

 

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.

* * * * * * * * * * * * * * * * * * * * * * * *

 

Dunnington, Wesley P

unread,
Jun 28, 2010, 1:11:57 PM6/28/10
to Kyle Meadors, wg-...@kantarainitiative.org, wg-iop

Hi Kyle,

 

Is there a working group call setup today? I don’t recall seeing any invites. Or is this a smaller working group?

 

Thanks

 

Wesley Dunnington
CA Technologies
Director, Software Engineering
Tel:  +1-508-628-8337
Wesley.D...@ca.com

image001.gif

Kyle Meadors

unread,
Jun 28, 2010, 1:16:41 PM6/28/10
to Dunnington, Wesley P, wg-...@kantarainitiative.org, wg-iop

It is the monthly eGov call. Colin sent an announcement to the eGov list, but you can join if you want.

 

Greetings all

 

REMINDER:

eGov WG Telecon Monday 28 June 2010

13:00 PST | 16:00 EST | 22:00 CET | 10:00 NZT

 

This telecon has been moved up from it's original calendar date of 5 July to account for the holiday.

 

* Skype: +9900827044630912

* US Dial-In: +1-201-793-9022 | Room Code: 4630912

 

Here is the draft agenda

 

http://kantarainitiative.org/confluence/display/eGov/eGov+Meeting+Agenda+Rev+1-+2010-06-28

 

 

Kyle Meadors

DGI

 

* * * * * * * * * * * * * * * * * * * * * * * *
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.
* * * * * * * * * * * * * * * * * * * * * * * *

image001.gif

John Bradley

unread,
Jun 28, 2010, 1:47:12 PM6/28/10
to Kyle Meadors, wg-iop, wg-egov@kantarainitiative.org Kantara
Kyle,

There are two features that I would have considered core and not part of eGov.

1. A IdP can configure signing and encryption per SP
2. A SP can be configured to only accept a subset of Signing and encryption, eg RSA-SHA256 but not RSA-SHA1 etc.

In some ways they are obvious but not necessarily covered.   Is there anything in the non eGov tests for this?

John B.

From: wg-iop-...@kantarainitiative.org [mailto:wg-iop-...@kantarainitiative.org] On Behalf Of Kyle Meadors
Sent: Monday, June 28, 2010 12:04 PM
To: wg-...@kantarainitiative.org; 'wg-iop'
Subject: [Wg-iop] eGov2 Test Cases - Next To Last Draft
 
I have done some high level editing of the eGov test cases. Several of the test cases were removed as they were already covered in the current test plan. Still, very grateful for those of you who did do the work but got the test cases removed. It was still good due diligence on our part to do it. And, if you feel your “cut” test case was not properly tested in the current test plan, please share why on today’s call.
 
On today’s call, we will walk through each test case and confirm they are IN or OUT or maybe just DEFERRED. We can also take time to make small adjustments but we don’t have time for lengthy discussion.
 
Also, I recommend we defer the IdP Proxying test cases which Bob Sunday did (and were quite good) as we never got test cases for Holder of the Key and thus can not fully test for eGov2-Full conformance. I recommend we put the proxying test cases in next year along with Holder of the Key so we can certify eGov2-Full.
 
I am looking for guidance on if some of these test cases can be successfully tested by just pairing up or testing against a single implementation. That is, it is NOT an interoperability test case where you need to verify the exchange points with all partners but a pure conformance/functionality test case that can be fully tested by just having a single partner/reference implementation. Error tests are typically in this latter category, but I am wondering if some of the metadata test cases can be tested with just a partner. The obvious benefit is it a single partner/implementation test is much faster, but we can’t do it if truly need full-matrix testing. This is a full-matrix interoperability test event.
 
Finally, we have to verify what we have is “feasible” to test. If the test case needs some extra test tools, especially in the error testing realm, then we may have to defer the test case until next year. Ultimately, that would be a decision of IOP WG and IRB but we can indicate where support is needed and they can decide where to try and test it this year.
 
 
Kyle Meadors
Drummond Group Inc.
Director of EHR Testing
Principal, Test Process
 
 
* * * * * * * * * * * * * * * * * * * * * * * *
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.
* * * * * * * * * * * * * * * * * * * * * * * *
 
_______________________________________________
WG-IOP mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-iop

Kyle Meadors

unread,
Jun 28, 2010, 2:19:23 PM6/28/10
to wg-...@kantarainitiative.org, wg-iop

For IdP security configuration per SP, yes, it is covered in core.

 

For a subset of signing/encryption, it is not called out in core nor have we ever tried to explicitly coordinate and test this functionality. The approach for security in core has been more of a minimum bar but also be supportive of higher levels from other participants. For eGov2, we could certainly make this an explicit requirement. However, try to deliberating to test for support of this would be tricky, at least without some type of error tool to support.

 

Kyle Meadors

DGI

 

* * * * * * * * * * * * * * * * * * * * * * * *
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.
* * * * * * * * * * * * * * * * * * * * * * * *

John Bradley

unread,
Jun 28, 2010, 2:47:16 PM6/28/10
to Kyle Meadors, wg-iop, wg-...@kantarainitiative.org
If the SP is configured to only accept RSA-SHA256 assertions as a US Gov endpoint must be after Dec 3.  

The simple test would be to send it a otherwise correct RSA-SHA1 and see if it accepts it.   Sending a warning to a upper level app would also be acceptable.

The concern I have is that if SP accept any supported algorithm automatically without allowing configuration that may be a serious security issue for some applications.    This is something that night not be easily observable by a SP.

John B.


_______________________________________________
WG-eGov mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-egov

Reply all
Reply to author
Forward
0 new messages