Let's not enumerate all possible failure paths as error messages.  Simply 
putting "unsupported_hash" is best.  The client then needs a way to discover 
allowed hashes.  You could register something like "supported_hashes" to allow 
that to be returned.
We really need to figure out if discovery will simply leverage OpenID 
deiscovery (which seems workable) or if we define something completely else. 

     On Wednesday, November 12, 2014 2:48 PM, Nat Sakimura <sakim...@gmail.com> 
wrote:
   

 I've thought about that, and I thought we could just add the error message 
when we add new alg. 
e.g., when we add SHA-3-256, we can add SHA-3-256_unsupported. 
On Thu Nov 13 2014 at 5:56:38 Mike Jones <michael.jo...@microsoft.com> wrote:

Is S256_unsupported or algorithm_unsupported the better error description?  I’m 
asking because I also expect that at some point in the approval process for 
this document you’ll be asked to support algorithm agility (for instance, being 
able to use SHA-3-256).                                                         
    -- Mike From: OAuth [mailto:oauth-boun...@ietf.org]On Behalf Of Nat Sakimura
Sent: Wednesday, November 12, 2014 10:49 AM
To: oauth
Subject: [OAUTH-WG] Adding machine readable errors to SPOP? As discussed at F2F 
today at IETF 91 OAuth WG, there has been some request to have a more fine 
grained machine readable error messages.  Currently, it only returns the error 
defined in RFC6749 and any more details is supposed to be returned in 
error_descripton and error_uri.  So, I came up with the following proposal. If 
WG agrees, I would put text embodying it into the draft-04. Otherwise, I would 
like to go as is. You have to speak out to put it in. (I am sending out -03, 
which we meant to send before submit freeze, without it..)  nError response to 
authorization requestlReturnsinvalid_request with additional error 
paramspop_errorwith the following 
values:▪S256_unsupported▪none_unsupported▪invalid_code_challengeClients MUST 
NOT accept the downgraderequest through this as it may be a downgradeattack by 
a MITM.nError response to token requestlReturnsinvalid_request with additional 
error paramspop_errorwith the following values:▪invalid 
_code_verifier▪verifier_challenge_mismatchnAuthorization server should return 
more descriptive information on lerror_descriptionlerror_uri   

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


   
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to