Kantara Initiative Identity Assurance WG Teleconference

Call recorded for purposes of note taking

Minutes approved, IAWG call 2013-04-11

Date and Time


  1. Administration:
    1. Roll Call
    2. Agenda Confirmation
    3. Minutes approval - IAWG Meeting Minutes 2013-03-14
  2. Discussion
    1. Agile IAF
    2. Errata
    3. Roadmap review
      1. Healthcare profile?
  3. AOB
  4. Adjourn


As of 14 January 2013, quorum is 4 of 7




Notes & Minutes

Agile IAF


I've got a question about the proper interpretation of AL1_ID_IPV#010 and #020: If read literally these conditions say that a AL1 IdP must provide In-Person Public Verification (base on self-asserted identity).

Why is this not an option for an IdP? The way I see it most IdPs operating at AL1 *only* would opt _out_ of IPV entirely (I suspect you won't be able to get a google account by showing up in person at G HQ for instance).

I propose the following change to the lean-in text of


"An enterprise or specified service must:"


"An enterprise or specified service that provides In-Person Public Identity Verification at AL1 must:"

To view/respond to the ticket, please login to the support ticket system.


we need to agree whether P3WG is providing input for the notices already required or providing additional/separate notices and whether the Privacy Assessment Criteria are directing assessors to evaluate the content of the required notices for privacy content or something else.

There are also requirements for information collected for identity verification/proofing, for credential issuance and management, and for records retention in Part B. I did not see any provisions that deal with the re-use of data derived from proofing or from logs of credential use (i.e., something that corresponds to the “no tracking” requirement under FICAM). I do not know of any review by the P3WG of the requirements or the language of IAF—and building in privacy protections here would seem to be fundamentally important. Should we not be integrating PAC into the existing framework in some way?


451 4.2.2 Notices and User Information/Agreements

452 These criteria apply to the publication of information describing the service and the

453 manner of and any limitations upon its provision, and how users are required to accept

454 those terms.

455 An enterprise and its specified service must:

456 AL2_CO_NUI#010 General Service Definition

457 Make available to the intended user community a Service Definition that includes all

458 applicable Terms, Conditions, and Fees, including any limitations of its usage, and

459 definitions of any terms having specific intention or interpretation. Specific

460 provisions are stated in further criteria in this section.

461 and actual Subscribers,

462 Subjects, and relying parties.

463 AL2_CO_NUI#020 Service Definition inclusions

464 Make available a Service Definition for the specified service containing clauses that

465 provide the following information:

466 a) Privacy, Identity Proofing & Verification, and Revocation and Termination

467 Policies;

468 b) the country in or legal jurisdiction under which the service is operated;

469 c) if different from the above, the legal jurisdiction under which Subscriber and

470 any relying party agreements are entered into;

471 d) applicable legislation with which the service complies;

472 e) obligations incumbent upon the CSP;

473 f) obligations incumbent upon the Subscriber/Subject;

474 g) notifications and guidance for relying parties, especially in respect of actions

475 they are expected to take should they choose to rely upon the service;

476 h) statement of warranties;

477 i) statement of liabilities toward Subscribers, Subjects and Relying Parties;

478 j) procedures for notification of changes to terms and conditions;

479 k) steps the CSP will take in the event that it chooses or is obliged to terminate

480 the service;

481 l) availability of the specified service per se and of its help desk facility.

482 AL2_CO_NUI#030 Due notification

483 Have in place and follow appropriate policy and procedures to ensure that it notifies

484 Subscribers and Subjects in a timely and reliable fashion of any changes to the Service

485 Definition and any applicable Terms, Conditions, Fees, and Privacy Policy for the

486 specified service, and provide a clear means by which Subscribers and Subjects must

487 indicate that they wish to accept the new terms or terminate their subscription.

488 AL2_CO_NUI#040 User Acceptance

489 Require Subscribers and Subjects to:

490 a) indicate, prior to receiving service, that they have read and accept the terms of

491 service as defined in the Service Definition;

492 b) at periodic intervals, determined by significant service provision events (e.g.

493 issuance, re-issuance, renewal) and otherwise at least once every five years, re494

affirm their understanding and observance of the terms of service;

495 c) always provide full and correct responses to requests for information.

496 of User Acceptance

497 Obtain a record (hard-copy or electronic) of the Subscriber's and Subject’s acceptance of

498 the terms and conditions of service, prior to initiating the service and thereafter at

499 periodic intervals, determined by significant service provision events (e.g. re-issuance,

500 renewal) and otherwise at least once every five years.

501 AL2_CO_NUI#060 Withdrawn

502 Withdrawn.

503 AL2_CO_NUI#070 Change of Subscriber Information

504 Require and provide the mechanisms for Subscribers and Subjects to provide in a

505 timely manner full and correct amendments should any of their recorded

506 information change, as required under the terms of their use of the service, and only

507 after the Subscriber's and/or Subject’s identity has been authenticated.


1. Potentially move the retention requirement to more reasonable in SAC core - but ensure that it's covered aligned to NIST requirement in US Federal Additional Criteria.
(Part of which set of changes?)

(See http://kantarainitiative.org/pipermail/wg-idassurance/2012-August/001326.html for thread of email discussion)
Roadmap discussion

Healthcare profile

General Roadmap overview


Next Meeting