Agenda
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.
Minutes
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.