[WG-IDAssurance] Consolidated comments on TFS documents
sshorter at electrosoft-inc.com
Fri Dec 6 15:00:29 CST 2013
Thanks again for great notes, Andrew, and for remembering the word
"provenance" for me.
On Fri, Dec 6, 2013 at 3:30 PM, Andrew Hughes <andrewhughes3000 at gmail.com>wrote:
> 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
> *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
> - 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
> - 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 126.96.36.199 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
> - 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
> *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
> *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
> *Identity Management | IT Governance | Information Security *
> WG-IDAssurance mailing list
> WG-IDAssurance at kantarainitiative.org
Scott Shorter, Principal Security Engineer, Electrosoft Services Inc.
sshorter at electrosoft-inc.com O: 703-437-9451 x21 M: 240-994-7793
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the WG-IDAssurance