Continued review of the (further) updated draft of the External ID Report draft at:
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.” 
- 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.
 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.