Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added notes

Attendees

Regrets

Agenda

Working Document - Use Cases and Errors

  1. SAML error states
  2. 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)
  3. Next steps

Notes

Working Document - Use Cases and Errors

  • See updates to the page

Reviewed proposed criteria for what should be included on the list of errors to be handled

  • These are reasonable, as long as we allow for changes if a particular use case requires it

SAML error states (and others we should consider)

  • Scott did his review and most SAML error codes are not likely candidates for the first round of work

    • AUTHN_FAILED - There are many circumstances where an IdP will send that status, but it’s usually when authentication is misconfigured

  • Should also consider a catch-all error code for “GENERIC" circumstances where the IdP itself wants to get involved

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

Join by Skype for Business
https://zoom.us/skype/560089711

Agenda

Working Document - Use Cases and Errors

...

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)

  • What information do we need to pass in the error URL to make it useful? What is the minimal set of information we can define? 

    • A transaction identifier - un-encoded (probably) fine; if yes, then URL encoding is not needed

    • A timestamp (EPOCH, 64 bit)

...

  • Note that where they show in the URL indicates whether or not they need to be encoded. If certain tags have to be in the query string, that changes whether they have to be encoded or not.

    • EntityID might be the only value we should have encoded

  • See proposed examples in the Working Document

Other considerations

  • SWAMID will set up a sample system to demo response pages for the five value types

  • Do any of the error states need more information that would help the IdP respond/react more quickly? We still need to be careful not to share information like what attributes are missing, etc., but if there’s anything that will allow the IdP to act without having to contact the SP would be good.

    • If IdP should contact SP, signal that?

    • If the SP has non-sensitive information that might be useful, signal that? (e.g., please support R&S)

      • Do these break the guideline for this to be user information?

Next steps

  • Next call to discuss any remaining technical requirements, and figure out how to document all this for community consideration; also look at demo system that SWAMID will probably have ready by then

...