Re: [OAUTH-WG] Adding machine readable errors to SPOP?
Thanks. I will dig it up. On Fri, Nov 14, 2014 at 10:54 Bill Mills wrote: > I sent some feedback on that section in a different message on list. > > > On Friday, November 14, 2014 12:41 PM, Nat Sakimura > wrote: > > > That pretty much was the conclusion we reached. I believe that it was what > the F2F room inclined to. So, for -04, we added a section on error response > but it doesn't have those granular errors. > On Fri, Nov 14, 2014 at 07:07 John Bradley wrote: > > Nat and I discussed it yesterday and I am still personally > unconvinced that the errors from the authorization endpoint are helpful. > So I am personally against adding specific errors for S256_unsupported > > > On Nov 14, 2014, at 6:52 AM, Nat Sakimura wrote: > > I find not much, if any. > > > On Fri, Nov 14, 2014 at 06:27 Brian Campbell > wrote: > > I struggle to see the value in adding more fine grained machine readable > error messages for this. > > Do we really want clients to try and negotiate the code_challenge_method > using browser redirects? Especially in light of the fact that we'll likely > also be discouraging AS's from redirecting on some error conditions when > there's no user interaction. > > On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura wrote: > > 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 request > lReturns invalid_request with additional error param spop_error with the > following values: > ▪S256_unsupported > ▪none_unsupported > ▪invalid_code_challenge > Clients MUST NOT accept the downgrade > request through this as it may be a downgrade > attack by a MITM. > nError response to token request > lReturns invalid_request with additional error param spop_error with the > following values: > ▪invalid _code_verifier > ▪verifier_challenge_mismatch > nAuthorization server should return more descriptive information on > lerror_description > lerror_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 > > > > ___ > 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
Re: [OAUTH-WG] Adding machine readable errors to SPOP?
I sent some feedback on that section in a different message on list. On Friday, November 14, 2014 12:41 PM, Nat Sakimura wrote: That pretty much was the conclusion we reached. I believe that it was what the F2F room inclined to. So, for -04, we added a section on error response but it doesn't have those granular errors. On Fri, Nov 14, 2014 at 07:07 John Bradley wrote: Nat and I discussed it yesterday and I am still personally unconvinced that the errors from the authorization endpoint are helpful. So I am personally against adding specific errors for S256_unsupported On Nov 14, 2014, at 6:52 AM, Nat Sakimura wrote: I find not much, if any. On Fri, Nov 14, 2014 at 06:27 Brian Campbell wrote: I struggle to see the value in adding more fine grained machine readable error messages for this. Do we really want clients to try and negotiate the code_challenge_method using browser redirects? Especially in light of the fact that we'll likely also be discouraging AS's from redirecting on some error conditions when there's no user interaction. On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura wrote: 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..) nErrorresponse to authorization requestlReturns invalid_request withadditional error param spop_error with the following values: ▪S256_unsupported▪none_unsupported▪invalid_code_challengeClientsMUST NOT accept the downgrade request throughthis as it may be a downgrade attack by a MITM. nErrorresponse to token requestlReturns invalid_request withadditional error param spop_error with the following values: ▪invalid _code_verifier▪verifier_challenge_mismatchnAuthorizationserver 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 ___ 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
Re: [OAUTH-WG] Adding machine readable errors to SPOP?
That pretty much was the conclusion we reached. I believe that it was what the F2F room inclined to. So, for -04, we added a section on error response but it doesn't have those granular errors. On Fri, Nov 14, 2014 at 07:07 John Bradley wrote: > Nat and I discussed it yesterday and I am still personally > unconvinced that the errors from the authorization endpoint are helpful. > So I am personally against adding specific errors for S256_unsupported > > > On Nov 14, 2014, at 6:52 AM, Nat Sakimura wrote: > > I find not much, if any. > > > On Fri, Nov 14, 2014 at 06:27 Brian Campbell > wrote: > >> I struggle to see the value in adding more fine grained machine readable >> error messages for this. >> >> Do we really want clients to try and negotiate the code_challenge_method >> using browser redirects? Especially in light of the fact that we'll likely >> also be discouraging AS's from redirecting on some error conditions when >> there's no user interaction. >> >> On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura wrote: >> >>> 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 request >>> lReturns invalid_request with additional error param spop_error with >>> the following values: >>> ▪S256_unsupported >>> ▪none_unsupported >>> ▪invalid_code_challenge >>> Clients MUST NOT accept the downgrade >>> request through this as it may be a downgrade >>> attack by a MITM. >>> nError response to token request >>> lReturns invalid_request with additional error param spop_error with >>> the following values: >>> ▪invalid _code_verifier >>> ▪verifier_challenge_mismatch >>> nAuthorization server should return more descriptive information on >>> lerror_description >>> lerror_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 > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Adding machine readable errors to SPOP?
Nat and I discussed it yesterday and I am still personally unconvinced that the errors from the authorization endpoint are helpful. So I am personally against adding specific errors for S256_unsupported On Nov 14, 2014, at 6:52 AM, Nat Sakimura wrote: > I find not much, if any. > > > On Fri, Nov 14, 2014 at 06:27 Brian Campbell > wrote: > I struggle to see the value in adding more fine grained machine readable > error messages for this. > > Do we really want clients to try and negotiate the code_challenge_method > using browser redirects? Especially in light of the fact that we'll likely > also be discouraging AS's from redirecting on some error conditions when > there's no user interaction. > > On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura wrote: > 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 request > lReturns invalid_request with additional error param spop_error with the > following values: > ▪S256_unsupported > ▪none_unsupported > ▪invalid_code_challenge > Clients MUST NOT accept the downgrade > request through this as it may be a downgrade > attack by a MITM. > nError response to token request > lReturns invalid_request with additional error param spop_error with the > following values: > ▪invalid _code_verifier > ▪verifier_challenge_mismatch > nAuthorization server should return more descriptive information on > lerror_description > lerror_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 smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Adding machine readable errors to SPOP?
I find not much, if any. On Fri, Nov 14, 2014 at 06:27 Brian Campbell wrote: > I struggle to see the value in adding more fine grained machine readable > error messages for this. > > Do we really want clients to try and negotiate the code_challenge_method > using browser redirects? Especially in light of the fact that we'll likely > also be discouraging AS's from redirecting on some error conditions when > there's no user interaction. > > On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura wrote: > >> 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 request >> lReturns invalid_request with additional error param spop_error with the >> following values: >> ▪S256_unsupported >> ▪none_unsupported >> ▪invalid_code_challenge >> >> Clients MUST NOT accept the downgrade >> >> request through this as it may be a downgrade >> >> attack by a MITM. >> nError response to token request >> lReturns invalid_request with additional error param spop_error with the >> following values: >> ▪invalid _code_verifier >> ▪verifier_challenge_mismatch >> nAuthorization server should return more descriptive information on >> lerror_description >> lerror_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
Re: [OAUTH-WG] Adding machine readable errors to SPOP?
I struggle to see the value in adding more fine grained machine readable error messages for this. Do we really want clients to try and negotiate the code_challenge_method using browser redirects? Especially in light of the fact that we'll likely also be discouraging AS's from redirecting on some error conditions when there's no user interaction. On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura wrote: > 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 request > lReturns invalid_request with additional error param spop_error with the > following values: > ▪S256_unsupported > ▪none_unsupported > ▪invalid_code_challenge > > Clients MUST NOT accept the downgrade > > request through this as it may be a downgrade > > attack by a MITM. > nError response to token request > lReturns invalid_request with additional error param spop_error with the > following values: > ▪invalid _code_verifier > ▪verifier_challenge_mismatch > nAuthorization server should return more descriptive information on > lerror_description > lerror_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
Re: [OAUTH-WG] Adding machine readable errors to SPOP?
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 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 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
Re: [OAUTH-WG] Adding machine readable errors to SPOP?
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 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 request > > lReturns invalid_request with additional error param spop_error with the > following values: > > ▪S256_unsupported > > ▪none_unsupported > > ▪invalid_code_challenge > > Clients MUST NOT accept the downgrade > > request through this as it may be a downgrade > > attack by a MITM. > > nError response to token request > > lReturns invalid_request with additional error param spop_error with the > following values: > > ▪invalid _code_verifier > > ▪verifier_challenge_mismatch > > nAuthorization server should return more descriptive information on > > lerror_description > > lerror_uri > > > > > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Adding machine readable errors to SPOP?
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..) •Error response to authorization request •Returns invalid_request with additional error param spop_error with the following values: ▪S256_unsupported ▪none_unsupported ▪invalid_code_challenge Clients MUST NOT accept the downgrade request through this as it may be a downgrade attack by a MITM. •Error response to token request •Returns invalid_request with additional error param spop_error with the following values: ▪invalid _code_verifier ▪verifier_challenge_mismatch •Authorization server should return more descriptive information on •error_description •error_uri ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
