Attendees
Meeting Invitation
Topic: Error Handling WG
Time: Feb 20, 2020 12:00 PM Pacific Time (US and Canada)
Every week on Thu, until Mar 19, 2020, 5 occurrence(s)
Feb 20, 2020 12:00 PM
Feb 27, 2020 12:00 PM
Mar 5, 2020 12:00 PM
Mar 12, 2020 12:00 PM
Mar 19, 2020 12:00 PM
Please download and import the following iCalendar (.ics) files to your calendar system.
Weekly: https://zoom.us/meeting/uJItd-GhqTor_piZ0ZQbAGlpqS9B-ipwVg/ics?icsToken=98tyKuyurjsiE9OUsVz9e7ItW6vlb8_ukE5eo5kNpi7nIgdfchLFb8APO6JoJt-B
Join Zoom Meeting
https://zoom.us/j/560089711?pwd=YktsRVBCKzJXdnlsZGwwZExydUN4UT09
Meeting ID: 560 089 711
Password: 591162
One tap mobile
+16699006833,,560089711# US (San Jose)
+19292056099,,560089711# US (New York)
Dial by your location
+1 669 900 6833 US (San Jose)
+1 929 205 6099 US (New York)
Meeting ID: 560 089 711
Find your local number: https://zoom.us/u/aRjU5ChSJ
...
Agenda
Working Document - Use Cases and Errors
- Discuss any additional error states
- Criteria: "Do we think that (most) IdP's are willing to write a support page for users for this error?"
- Additional fields (focus on what different information pages the IdP's want to have; the error codes should be mapped one-to-one with that)
- Next steps
Notes
- Discuss any additional error states
- Criteria: "Do we think that (most) IdP's are willing to write a support page for users for this error?"
- "attribute value too large" and "bad attribute value” and various of the SAML status error codes might be useful
- Bad attribute value: if an SP is using some of the new attributes, but those attributes (e.g., subjectID) seem to be in conflict with other data in the system (two identical subject identifiers for separate users)
- What on the list is actionable? What do you want the user to be in the middle of resolving? Note that another perfectly valid action is to simply indicate “We’ve logged the issue; someone will be in touch [with the IdP]”. Since the SP doesn’t know what the IdP will want to do, the SP can’t tell the IdP to do any particular thing.
- Perhaps we just need a generic “catch all” case for everything not otherwise covered? Note that it’s only the IdP knows who the right contact is at any given institution.
- What is our benchmark? Options include:
- If the error must be something actionable by the user, then we should not include any generic information.
- If the IdP has told the SP that the IdP wants the error handled a certain way, then that’s what we want to see in the error code; this may not be something the user can act on.
- If all the IdPs will respond to a particular condition in a particular way, is that a reasonable response that will fit into this proposal? Will the SPs be happy with the outcome they get in reporting those issues to the IdP? The SP should be the ones driving the SPs satisfaction with the UX in implementing this proposal.
- Consensus: If the common use case for a given error can is not something the user can do something with, something that can be handled behind the scenes by the technical contacts, then it out of scope for this WG.
- bad attribute value and value too large (as discussed on list) are out of scope
- MISSING_ATTRIBUTES, AUTHZ_FAILURE, and REQ_AUTHN_CONTEXT are all in scope. “You are not authorized to access this content. If you think you should be able to access this contact, please contact your IdP."
- AUTHN_TOO_OLD (probably a FORCE_AUTHN error) might be out of scope; this is more an IdP error than anything the user can do something with other than start over.
- SCOPE - in practice, the software that understands scope tends to drop and filter out the info, so it’s indistinguishable from not receiving it. This will look most like a bad attribute value. Out of scope.
- Scott Cantor to review the SAML states and report to the list if any of them might be reasonable for us to consider as a common error state
- Next steps
- Next call, 5 March - usual time. Will discuss the Scope error state and Additional Fields
- Reminder: Call on 12 March will have the DST insanity where Europe switches before the US