[Wg-idassurance] Comments on Service Assessment Criteria
frank.villavicencio at netstar-1.com
Sat Oct 10 00:07:23 EDT 2009
Thanks so much for this thorough first past. I am really glad to see
this initiative to leverage the SAC as a baseline for your client to
adopt identity assurance internally.
We are in the process of updating the documents and re-branding them
(from Liberty to Kantara), so your timing is actually very good.
When do you estimate completing your review? Perhaps we can compile the
entire list and then discuss it. I wonder if you are OK sharing your
spreadsheet with this group - it may be a useful document.
I wonder what the group thinks about carving out time in one of our
upcoming calls to go over this feedback. I think that it will be a good
exercise to get some of the new IAWG members a practical round of
discussion on the IAF - what do you all think?
From: wg-idassurance-bounces at kantarainitiative.org
[mailto:wg-idassurance-bounces at kantarainitiative.org] On Behalf Of Erik
Sent: Friday, October 09, 2009 1:35 PM
To: wg-idassurance at kantarainitiative.org
Subject: [Wg-idassurance] Comments on Service Assessment Criteria
I'm currently writing an assurance level guide for a crown corporation
in Canada. I'm basing my guide on the SAC guide plus some other federal
documents. This is a great document. I'd be curious to know about its
history and background (especially where the standards levels come
Here are some comments about the latest document (0.5)
A little technical detail first:
ALX_CO_NUI#060 and ALX_CO_NUI#080 are not used and are not described in
the document, they can probably be removed
On the form:
I spent some time building a excel spreadsheet with all the requirements
- in order to understand the delta between each AL. I found out that
some requirements are similar accross all levels, some have only a
security level inside the requirement that changes, others are the same
I would suggest using a single reference for the requirement instead of
Maybe the same could be done for requirements that depend only on a AL
These little details would help the readability IMO.
On the content:
* CSP should be defined early and in the glossary
* I have some issues with current AL2 standards:
* Why does Remote verification requires a Government
Picture ID? Wouldn't any government ID be enough for verification over
Internet or phone?
* Wouldn't one credential be enough in AL2_ID_RPV#10?
* AL2_CM_CRD#015 seems rather close to AL3 requirements.
For what we intend to do with AL2, it seems rather too strong. same for
AL2_CM_CRD#016 which verifies only the address or phone number - not the
* I have the same issue with AL3 and remote verification with
* In AL4_ID_IDV#000 shouldn't face-to-face be "In person public
* I haven't figured what all the [Omitted] stand for in the
* Why is there AL1_CM_IDP#10 since AL1 is self asserted? same for
* ALx_CM_CRN#070 shouldn't the FIPS level be the same as the AL?
* AL3_CM_RVP#060 shouldn't this refer to AL3_CM_CPP#010 instead of
I'm still working on this document, so I might have more comments
"IMPORTANT NOTICE: This transmission is intended to be delivered only to the named recipient(s) and may contain material that is confidential, proprietary or subject to legal or other protection or privilege. If you are not the intended recipient(s) (or authorized to receive for the recipient), please contact the sender by reply email immediately and delete all copies of this transmission from your systems. Review, dissemination or disclosure, further transmission or other use of, or action taken in reliance on information contained in this transmission by anyone other than the intended recipient(s) is not authorized."
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Wg-idassurance