[WG-IDAssurance] Consolidated comments on TFS documents

Scott Shorter 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
> 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 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 *
> _______________________________________________
> WG-IDAssurance mailing list
> WG-IDAssurance at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-idassurance

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...
URL: <http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20131206/fe068800/attachment-0001.html>

More information about the WG-IDAssurance mailing list