search

KantaraInitiative / DistributedAssurance

Distributed Identity Assurance Specification
2 stars 2 forks source link

Add error responses from csp #10

Open TomCJones opened 4 years ago

TomCJones commented 4 years ago

Need to gracefully handle the case where the user data or the doi submitted to the csp is insufficient for creation of a certificate with the requested level of assurance. This needs to lead the user to fix the problems without giving too much information to an attacker.

nwhysel commented 4 years ago

This would be part of the redress function.

Noreen

On Jan 29, 2020, at 5:02 AM, tom jones notifications@github.com wrote:

 Need to gracefully handle the case where the user data or the doi submitted to the csp is insufficient for creation of a certificate with the requested level of assurance. This needs to lead the user to fix the problems without giving too much information to an attacker.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

TomCJones commented 4 years ago

From Noreen's comment, i think we need a two part answer:

  1. the UX of this - perhaps Noreen or Mary could comment. 2 the interchange spec, for example: { operation : "fetch csp" error : "invalid_request::" error_description : "Must be at least 3 parts to a jose request" error_uri : "https://someusefulfacts.com#fetch_csp&invalid_request" } we could also designate an error code for human action unsupported_grantt:type --> this csp does not provide that service unauthorized_azcode --> the doi from the issuer (PDP) was denied the uri field could be inlcuded on the ux as a link
nwhysel commented 4 years ago

The error message should have actionable information. What are the three parts to a JOSE request? which part is missing? etc. People don’t know what a uri, doi or grannt code is.

I like error messages that either show the technical information that a developer might understand along with something in plain English that a user without technical experience can understand or have a button so they can send the error to someone who can act on it. The display could differentiate with a different font and have some kind of instruction about who might be able to help with the technical error. Best case is to make it seamless by having them “click to send an error report” which can forward to a responsible party.

Noreen

On Feb 13, 2020, at 2:42 PM, tom jones notifications@github.com wrote:

 From Noreen's comment, i think we need a two part answer:

the UX of this - perhaps Noreen or Mary could comment. 2 the interchange spec, for example: { operation : "fetch csp" error : "invalid_request::" error_description : "Must be at least 3 parts to a jose request" error_uri : "https://someusefulfacts.com#fetch_csp&invalid_request" } we could also designate an error code for human action unsupported_grantt:type --> this csp does not provide that service unauthorized_azcode --> the doi from the issuer (PDP) was denied the uri field could be inlcuded on the ux as a link — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.