DRAFT External Identities Work Group Meeting - 2015-02-26

Agenda

  1. Review updated outline for workgroup report
    1. Effort has gone into creating a draft document together, but much of our effort has revolved around the key elements (criteria, use case simplification, etc.) to use in discussing the problem in general. Based on our conversations, we’ve updated the outline. It doesn’t look too different from the original outline proposal, but it’s got some additional focus/clarifications that we wanted to discuss with the group before putting more effort into creating an actually readable draft document.
  2. IAM Online recap (from 2/11/2015) and discussion of participant comments/questions. The questions I documented from the discussion are noted below:
    1. Are there any specific recommendations around how external IDs would be added/managed in e.g., Grouper (with and without a related invitation service).
      1. Is use of externalized authorization a specific recommendation of the group?
      2. E.g., use and storage of human-friendly IDs (email address, google account) vs. external ID system unique (and generally opaque) IDs.
    2. Are there specific recommendations on use of external IDs as a protection for password reset (as Mary described VT does)?
    3. Are there specific recommendations for additional security to use when allowing external ID-based authentication? (this was asked indirectly and off-line, so may not have been seen) E.g.:
      1. Authenticating a user’s device via an “institutional account” and limiting external ID use to authenticated devices (in certain use cases).
      2. Only allowing external IDs in conjunction with (institutionally supported) 2-factor authentication (in certain use cases).
  3. Other items that are in the workgroup charge but not necessarily explicitly addressed in previous discussions
    1. Define and document how a gateway would represent the properties of an external account to an application.
  • The new version of Outline for Final Report
    • People like the organization (or were silent)
    • Organization of Use Case Dimensions section is intended to bridge between use cases and architecture
    • VOs may have own infrastructure, or be part of campus infrastructure.  Also, they may look like their own institution within the federation or not.
  •  IAM Online recap (from 2/11/2015) and discussion of participant comments/questions.

    • We won't make recommendations about group management, but we will say that management and use of external IDs should be aligned with internal IDs.
    • Ian mentioned that Cirrus is seeing increased requests for asserting institutional identities based on social authentication.
    • We touched on issue of password reset and other methods for mitigating risk.  We'll discuss more via electronic mail, but may make a suggestion for future work.

Action Items

  • Eric, John, and David will continue work on the draft report.
  • No labels