Comment 1 - disagree with complicating the protocol. If there’s a need of the SP to maintain control of the user, suggest the SP open a new window. Note that the user is already blocked, which is why this error protocol exists. We send the user back tot the IdP because the SP cannot do anything further - there is no reasonable way to continue from the SP’s perspective.

Comment 2 - the friendly name is under the control of the IdP; if the SP passes that back then the IdP will be well positioned to handle this. If the SP creates a new name, that might create more problems than it solves The alternative would be to put in more language specific to every protocol. We could be more specific with attribute names to include the protocol, and direct away from friendly names. It will be longer names that humans can’t read because they will be OIDs. Since this is originally expected to be human readable, there is some conflict about whether using OIDs would actually be better (more precise, less human clear). 

Comment 3 and 4 - Some attributes are used for authorization, and missing them means you have no authorization. The SP doesn’t always know if it’s a problem of missing attributes or if the user is actually not authorized (the missing attributes may be intentional). But not all missing attributes will result in authorization failure issues (e.g., authorization is rarely if ever done on name attributes). 

Next call: Thursday, 28 May, usual time; will discuss remaining comments. A separate call will be scheduled to discuss responses with the community