[WG-IDAssurance] Consolidated comments on TFS documents

Andrew Hughes andrewhughes3000 at gmail.com
Fri Dec 6 14:30:38 CST 2013


Hi all - here's the consolidated list of comments on the TFS drafts.

Joni - over to you for merging with the ARB comments

And here are the meeting notes if you'd like to see the discussion on some
of the items (also available in the IAWG Meeting Minutes for December 5
2013)

*FICAM TFS Program update comments from IAWG members - December 5 2013
meeting notes*

   - RF: the ATOS seems to be making the CSPs into Attribute Providers -
   the current requirement is to only maintain core attributes - there seems
   to be an extension into a new set of attributes - this would increase
   costs, might knock smaller CSPs out of the running because they may not
   have the resources to deal with the extra attributes.
   - RF: Anil John referenced ANSI/NASPO Section 6
   - MF: Read it as an optional requirement - if they are available then
   provide the attributes, if not then no issue.
   - RF: Verbal indications that the attribute provision is leaning towards
   mandatory provision (because the Federal Agencies might ask for them)
   - SS: There is a section in the RP Guidance on disambiguation of
   identities - it recommends that the agency goes to an attribute provider
   without any reference to LOAs.
   - CT: Anil mentioned that this set of attributes is needed for the RPs
   to perform account/identity disambiguation and linking to the right agency
   account
   - MF: most RPs don't identify their clients from these attributes - they
   know them by other information
   - RF: do the SAML assertions have to include the extra attribute data?
   If yes, then the CSP will have to capture and maintain the extra attributes.
   - SS: don't these attributes have to be collected and kept as proof of
   the ID Proofing process?
   - RF: yes. but they do an encrypted hash of the values
   - MF: But there are many attributes that are not currently collected
   - RF: The registration authority does not store the information - the
   Certificate Authority keeps it if they want to or need to.
   - SS: It appears that Verizon would meet the Bundle 1 requirements.


   - Section 7.2.2.3 discusses how to resolve problems linking CSP-provided
   identities to accounts. Recommended methods to resolve include:
      - Trusted third party. This method redirects a user to a third-party
      site (e.g., Experian) where he/she is prompted with several questions to
      verify his/her identity.
      - Help desk/call center. This method requires the user to call the
      help desk to resolve linking issues. The help desk can ask a series of
      questions to verify his/her identity.
   - Now should those "several questions" or "series of questions"
   correspond to the LOA of the identities in question?


   - SS: If they are looking for verified attributes, then it has to be
   better defined.
   - MF: It is unclear if the attributes SHALL be sent if the CSP has them
   or if they are optional.
   - RW: Are we making the assumption that the RP will be dictating the
   attributes that the CSP will have to gather in the ID Proofing process?
      - (RF: Yes)
      - So, is this assumption correct?
      - (RF: Vz reading is that if the RP asks for it, then the CSP pretty
      much has to provide it)
      - This needs clarification
   - RW: The requirements are stated in terms of what the RP must do. The
   implication that is not clearly stated is that the imposition on the RP
   becomes an implication on the CSP. This is essentially a profile imposed on
   800-63-2 -> "these are the things needed to sufficiently define an
   'identity'"
   - MF: consolidate Scott's item with Rich's item
   - RW: There's also an issue with the footnote saying 'in order of
   preference' -> this implies that beyond the core attributes, it is not
   clear what weighting the additional attributes have (the core gets 96%
   certainty, so what do the others provide?)
   - RF: Danger is in who is interpreting this - CSP will see it one way,
   Federal RP will interpret differently.
   - RF: If adding Attribute Providers into the CSP process, it's possible
   that the price of the CSP services will rise which might become an
   inhibitor to RP uptake.
   - ALL: review comments that have been circulated so far for tomorrow's
   call


*FICAM TFS Program update comments from IAWG members - December 6 2013
meeting notes*

Myisha Frasier-MacElveen (Chair), Rich Furr (Vice-Chair), Andrew Hughes
(Secretary), Peter McDonald (Symantec), Nathan Faut (KPMG), Cathy (Daon),
Scott Shorter (Electrosoft), Bill Braithwaite



   - SS: gave overview for 1st eSoft comment
   - PM: Submitted a question around what 'Verified' means - Verified is
   probably distinct from Assurance Level
   - SS: For these Verified Attributes - is there any difference between
   - PM: Scenario: At LOA2 and LOA3 if a person gives a fingerprint and zip
   code -> this uniquely identifies an individual. So is the zip code a
   Verified Attribute or not?
      - There's not enough clarity on how this is intended
   - SS: Identity Proofing only establishes that the identity is a real
   person - it does not actually say anything about the person being the
   person claiming the identity
      - Need to either include gradations of 'proof' so that this is not an
      absolute
      - Need to work out how post-registration identity changes should be
      used to maintain the integrity of the initial proofed identity
   - RF: CSPs do a pretty thorough process to establish that the identity
   information relates to the actual person - either by in person or using
   antecedent information
      - Never 100% perfect but it is well-understood process
   - SS: maybe the RPs would be served better by having ID Proofing process
   metadata -> that gives hints about provenance -> so the RP can assess risks
   properly
   - BB: the 'real person' establishment has been subsumed into the process
   of 'identity resolution'/ 'identification of an individual'
   - SS: general comments on use of more standardized requirements language
   e.g. 'shall', 'should', etc
   - MF: ATOS document p4 discussion - the reference to Financial
   Institutions exemption. The identity vetting processes depends on the type
   of account - so hard to deal with LOA equivalence
   - PM: Definition of verification - e.g. Name - what is needed for name
   variants? For some attributes variants might need to be allowable.
   - PM: Concern that if CSPs need to become full-blown attribute providers
   will require significant resources and investment
   - PM: discussed Symantec's comment re verified attribute sources
   - PM: if a CSP has to go to additional sources to verify attributes then
   the CSP's financial model changes


thanks
andrew.

*Andrew Hughes *CISM CISSP
Independent Consultant
*In Turn Information Management Consulting*

+1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8
AndrewHughes3000 at gmail.com
ca.linkedin.com/pub/andrew-hughes/a/58/682/
*Identity Management | IT Governance | Information Security *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20131206/9ed8fc4a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IAWG Consolidated FICAM_TFS_Comment Matrix_20131111.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 49629 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20131206/9ed8fc4a/attachment-0001.xlsx>


More information about the WG-IDAssurance mailing list