2024-04-04 IAWG Meeting Notes

status:quorate

status:approved

2024-05-16 IAWG Meeting Agenda/Notes

1. 2024-03-28 IAWG Meeting Notes

No objections, motion carries.

Overview, Identification, and Authentication Concept Maps from ISO SC 27/WG 5 (attached and in 2024 Meeting Materials)

Andrew Hughes

• Kantara has a liaison with ISO SC27/WG 5 (scope is security of identity management, privacy technologies, and biometrics)

• Andrew Hughes serves as a delegate to this group from Canada.  

• Current challenge-reaching agreement on what identity management processes cover

  1. FIDO style v. info management (attributes) v. digital identity etc.

  2. Definitions, concepts, etc. 

• Concept maps came out of an ad hoc group, as a potential, informal explanation/description for these topics and how they are interrelated.

  1. Not looking to modify, just seeking confirmation that they are sensible/useful.

•  Overview - Enrollment Process Map 

  1. Relationship diagram for overall enrollment process (goal is to identify and register the entity)

     1. Identification process goal-fully outlined in identification process map

     2. Association process goal

        1. Entity association binding outlined in identification map

        2. Authentication association/binding outlined in authentication map

     3. Authentication process goal-determines if claiming entity is the same as registered entity

• Identification Process Map

  1. Linking phrases are arbitrary

  2. Debate is what needs to appear in map, not precise annotation, but it’s about getting enough relationship information recorded so that if a discussion about domain policies takes place, a quick understanding/reference is available for use in that discussion

  3. High level

  4. Registration process-not yet mapped out

  5. Where do stolen identity/duplicate claimant/fraud issues fit in?  Perhaps a resolution process?  Should this be included in this map? 

• Authentication Process Map

  1. Similar set-up to other maps (high-level, provides enough information to be a reference during discussion)

  2. Core-involves verification and the challenges/outputs/data/methods associated with this

  3. Process for “something is changing” on behalf of the user/subscriber?

     1. i.e. travel notices

• ISO work group has a diverse group, with each member having a fixed view on how identity management works.  A goal of these maps is to offer a way to talk about the central underlying theme of exactly what they are trying to standardize

  1. Challenges: outdated standards and lack of consensus

• Which audience is this for?   Is it for new people to learn/gain information or for experienced people needing guidance/structure in arcane conversations? Both - Knowledge sharing and localization tool

• Maps can also be used to find gaps/missing links

• Maintenance of identities?  Is this being intentionally avoided? Would it be a separate concept map? 

  1. Conflicting views regarding identification: 

     1. Purpose of identification is to create a record of data pertaining to the entity that can then be shared with other authorized parties

     2. Purpose of identification is to assign an authenticator or credential/certificate, which then represents the entity and allows them to be recognized when they return to a place

     3. The data collected at enrollment is not the primary reason for identity.

• Identity management:

  1. Identity information management-info/attributes pertaining to an entity/individual (Make as complete/accurate list or registry as possible)

  2. Identification and returning identification-technical process

• Possible need for a map for administration/management/maintenance?

  1. Information record for entity

  2. Information standing behind an authenticator or credential

S3A; criteria (Assurance Program considerations)

Jimmy Jung

• Seeking to lay down structure/standards/workflows to increase ARB’s understanding of the systems that are under review and  increase consistency within the program

• Possibly introduce requirements for providing more detail by augmenting the S3A template 

• Screen share information:

  1. The Cyberdyne Skynet service supports the following configurable workflows:

     1. Unsupervised remote proofing at IAL2 (leveraging Experian)

     2. Supervised remote proofing at LOA3 and IAL2 (Webcam proofing

     3. Supervised In Person proofing at LOA3

  2. The Cyberdyne Skynet service requires the following evidence types identified by SP 800-63-3

     1. 1 STRONG and 2 FAIR (leveraging Experian)

     2. 2 STRONG

  3. The Cyberdyne Skynet service supports multifactor authentication using passwords and one of the following:

     1. Out-of-Band Device using SMS or Voice One-time Passwords

     2. Single-Factor OTP Device using a Time-Based One-Time Password Application (TOTP)

     3. Single-Factor Cryptographic Software using the Authy mobile authentication application.

  4. FIDO based authentication is being considered for future implementation

• The Cyberdyne Skynet service performs authentication using the following protocols:

  1. SAML

• Jimmy: 63B#0120 is pulled directly from 800-63B and “requires verifiers to meet FIPS 140 Level 1 or higher”.  However, FIPS 140 criteria has mostly been avoided by the Assurance Program.  What do they want here? That cryptographic authenticators should meet FIPS 140?