[Wg-idassurance] Comments on Service Assessment Criteria
Richard G. WILSHER (Zygma)
RGW at Zygma.biz
Sat Oct 10 01:15:26 EDT 2009
As the principal author/editor of this work, pls permit me a few
observations on your input, not the least of which is that it is good for
Kantara that you should be giving such credibility to the SACs and any
real-world feedback is of great value.
Further comments are in-line.
Richard G. WILSHER
the Zygma partnership LLC
Office: +1 714 965 99 42
Mobile (USA): +1 714 797 99 42
Mobile (Eur): +44 77 68 05 41 58
<mailto:RGW at Zygma.biz> RGW at Zygma.biz
From: wg-idassurance-bounces at kantarainitiative.org
[mailto:wg-idassurance-bounces at kantarainitiative.org] On Behalf Of Erik
Sent: 09 October 2009 17:35
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 from).
*RGW - As a starting point, refer to FIPS 201, the FICC Criteria and OMB
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
*RGW - Actually, they ARE described, as 'Withdrawn', the explanation for
which is given on p8, lines 199/200. This is an important consideration in
allowing for back-ward compatibility from the implementer's perspective.
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 between ALs.
*RGW - changes at ALn vs. AL(n-1) are now shown using bold text. As I
understand it you are working from doc IAF-2200 v0.5. I refer you to page 7
lines 186/187 where this is explained.
I would suggest using a single reference for the requirement instead of
*RGW - This has been considered in the past but rejected because, as
presently structured, a complete set of criteria can be excised in a single
block of text, whereas using a single instance for criteria which do not
change requires the user to know which criteria these are.
Maybe the same could be done for requirements that depend only on a AL
*RGW - See above
These little details would help the readability IMO.
*RGW - It is my opinion that the document as structured is preferable,
particularly since it is quite clear when there is no change (no bold).
On the content:
* CSP should be defined early and in the glossary
*RGW - seems fair
* 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
*RGW - I think this is reflective of FIPS 201, but this is an unverified
* 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 identity
* I have the same issue with AL3 and remote verification with picture
* In AL4_ID_IDV#000 shouldn't face-to-face be "In person public
*RGW - It certainly could be.
* I haven't figured what all the [Omitted] stand for in the document.
*RGW - I again refer you to page 7 lines 186/187 where this is explained.
* 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 later...
*RGW - and these are knee-jerk responses, so any comments requiring real
thought I have not addressed, just the ones I could deal with from memory or
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Wg-idassurance