Child pages
  • External Identities Work Group Meeting - 2015-04-09
Skip to end of metadata
Go to start of metadata


Continued review of the (further) updated draft of the External ID Report draft at:

Pre-Meeting Notes

distributed with agenda

We believe we are at a near final draft, so please review and see if there are any glaring errors, omissions or concept manglings.

Latest edits include:

  • Addition of Executive Summary
  • Bulletization (and reduction of prose) in “Architectural Approach” section
  • Consistentization of the use of terms such as “SP”, “RP”, “service”, “application”, etc.
  • Removal of extraneous uses of the word “etc.” [1]
  • Addition of sample references back to content in the “Concerns with using External IDs” Appendix
    • This was promised on the last call to see if this is a useful approach (Spoiler alert: I’m not sure it is)
    • Consolidation of the two Appendices (“Concerns with using External IDs” and “Criteria for Evaluating External ID Providers”).
      • I think I’ve been convinced this is a better approach, but leaving the two sections for group consideration

What is not included:

  • On the last call it was also suggested that we should have some call out of how one might architecturally approach External ID integration for non web/http applications. We didn’t find a good way to put in commentary, nor am I sure exactly what should be added, so this can be a topic on the call if the topic still resonates.

[1] If you are wondering, yes, the misuse of "such as...etc" in the previous bullet was intentional and intended as irony.


Is the document valid for non-browser authentication?

  • We don’t have real protocols for non-browser authentication
  • Is it that it’s applicable generally, but not really in a way that supports actual implementations?
  • Are there any use cases that are relevant?
    • Probably all Authentication protocols are themselves http based, even though the implementations may not all look like that (eduRoam, SSH/Moonshot)
    • Added comment on the other protocols here.
      • Should protocols supported be added to the list of criteria?
      • Including non-browser authentication?
      • Should we add to the ext provider and relying party not being required to prompt for credentials?

Need a concluding brief and concise paragraph or section.

Potentially recommendations for future work?

Look at Trustworthiness section to see if bullet points are duplicative of the other sections.

  • Action Item: Edits/Fixes by tomorrow
  • Submit to TAC right after, ask for comments end of next week
  • Then greater commenting to InCommon participants (or other general purpose lists) for a week or so.
  • Then back to TAC in three weeks.

Removed this recommendation from the document, not because it's a bad idea, but because it's the only recommendation for future work embedded in the document. Instead, we will focus on capturing potential recommendations for future work in a separate document.

Recommendation for future work: Details of how an invitation service would be implemented, including the UI presented to inviters and invitees, what information is captured during the invitation process and what Attributes/Identifiers are used to manage the linkage of the External Identifier to the invitee’s authorization service.


  • No labels