[WG-IDAssurance] Proposed extension of the IAF scope

[Rainer Hörbe]

The following text is an input for today's agenda item on the road map.

The scope of LoA in some frameworks like the IAF, 800-83, ISO 29115 and STORK is defined as “confidence in the identity information presented by a CSP”, explicitly limiting the scope to the credential itself, or the authN instant and the processes the authN depends on.

In the recent discussions on the IAWG and P3WG lists we reached some agreement that this AuthN Assurance is a subset of the total set of trust relationships that needs to be considered. The proposed Trust Framework Meta Model (as discussed during the RSA conference in February) shall provide the definitions, structure and tools to map this problem space, provide a gap analysis between existing frameworks like the IAF and some reference trust framework.

As the meta model project requires some effort and some sponsoring, it will probably take some month (hopefully not more) to complete. As trust frameworks are being implemented in current projects, and new standards emerge (like ISO 29115), I would like to take some of the preliminary conclusions from the Meta Model and propose extensions to the IAF, with the intent put this on the IAWF road map without waiting for the complete results. The meta model will still be needed, particularly in the area of delimitation to the privacy framework and for gap analysis, but I think that some results can be argued without digging into a more detailed level.

The current IAF limits the scope to those requirements that a CSP can fulfill. Yet the benefit of the IAF to a RP is to provide shrink-wrapped policies named LoA-1 to LoA-4, so that the RP can use to mitigate the risk of providing its service to remote users. However, the current definition of LoA is limited to the processes that use the credential or authN assertion, leaving it up to the PR to assess the remaining protection requirements. Given the fact that the trust relationship between RP and CSP implies a trust relationship between the CSP and subject, it does make sense to use it to address the remaining protection requirements.

E.g, an EHR’s confidentiality and integrity needs to be kept for the whole transaction or session, eventually even beyond the electronic system when requiring secure printing. A LoA is a means of automatically negotiating policies; having multiple “levels of some-protection-requirement” would be too complicated for both policy mapping and policy enforcement. So, instead of having a pre-authentication-LoA and post-authentication-LoA a single LoA should include all identity-related protection requirements that are concern of the infrastructure level.

Proposed change:

V 2.0

new

An assurance level (AL) describes the degree to which a relying party in an electronic business transaction can be confident that the identity information being presented by a CSP actually represents the entity named in it and that it is the represented entity who is actually engaging in the electronic transaction.

An assurance level (AL) describes the degree to which a relying party in an electronic business transaction can be confident that the identity information being presented by a CSP actually represents the entity named in it and that it is the represented entity who is actually engaging in the electronic transaction. Each LoA also describes the level protection of confidentiality, integrity and accountability of the transaction that is based on the assured identity.

This change would of course imply the addition of assurance criteria for session protection, authZ, etc.

There are 2 pictures in the attached document to illustrate the text above.



- Rainer



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20110302/ad86e61f/attachment-0002.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IAF-extended LoA.ppt
Type: application/vnd.ms-powerpoint
Size: 462336 bytes
Desc: not available
Url : http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20110302/ad86e61f/attachment-0001.ppt 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20110302/ad86e61f/attachment-0003.html