[Wg-idassurance] Comments on Service Assessment Criteria

Sat Oct 10 01:15:26 EDT 2009

Erik,

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.

Regards,

Richard.

Richard G. WILSHER
CEO
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
 <BLOCKED::http://www.Zygma.biz> www.Zygma.biz 

  _____  

From: wg-idassurance-bounces at kantarainitiative.org
[mailto:wg-idassurance-bounces at kantarainitiative.org] On Behalf Of Erik
Putrycz
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
M-04-04

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
repeated ALx_xxx_xxx

*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
number?

*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
phone?

*RGW - I think this is reflective of FIPS 201, but this is an unverified
statement.

*	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
ID
*	In AL4_ID_IDV#000 shouldn't face-to-face be "In person public
verification instead"?

*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
AL1_CM_CRN#10
*	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
AL2_CM_CPP#010?

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
with ease.

Thanks

Erik.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20091010/2f0fe269/attachment.html 