I hear that many folks don't want to add a mandatory crypto operation on the
client side :-(
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, February 23, 2016 3:17 PM
To: Roland Hedberg
Cc:
Subject: Re: [OAUTH-WG] Fixing the Autho
The idea of including the state in the PKCE calculation was one I think Hans
brought up at the meeting in Darmstadt.
I think we discounted it as not solving the problem because the attacker could
manipulate the code_challenge.
As and example the attacker receives the request and changes the cod
I would go with option A, option B introduces concepts/syntax that complicates
the current Oauth model
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Friday, February 19, 2016 11:43 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Fixing the A
Hi
On 23/02/16 19:31, Antonio Sanso wrote:
hi Sergey,
just my 2 cents
let’s start from a simple fact that encryption is not authentication. :)
And since then the access tokens are supposed to provide the source
guarantee to the client ? Can you point to any text somewhere suggesting
the client
In line !
> 22 feb 2016 kl. 05:08 skrev John Bradley :
>
>> On Feb 22, 2016, at 9:22 AM, Nat Sakimura wrote:
>>
>> The risk impact of [case2] is more OAuth specific. The token is stolen as
>> the token is going to be sent to a rogue resource, and the resource can use
>> that to obtain the res
Hi Sergey,
JWE will indeed make the token content confidential to clients. However,
without a proper signature (RSA or EC, HMAC in JWS doesn't qualify), the
RS cannot establish the origin of the token. With symmetric crypto (e.g.
JWE alg=dir) anyone who has the shared key will be able to create a
hi Sergey,
just my 2 cents
let’s start from a simple fact that encryption is not authentication. :)
Now, if the claim sets of a JWS contains only not confidential information JWS
is enough.
See also inline
On Feb 23, 2016, at 6:15 PM, Sergey Beryozkin wrote:
> Hi
>
> Some OAuth2 providers m
Hi
Some OAuth2 providers may return self-contained access tokens which are
JWS Compact-encoded.
I wonder is it really a good idea and would it not be better to only
JWE-encrypt the tokens. I'm not sure JWS signing the claims is
necessarily faster then only encrypting the claims, assuming the
Comment starts at line 173 :)
On 22/02/16 14:08, John Bradley wrote:
> Inline
>
>> On Feb 22, 2016, at 9:22 AM, Nat Sakimura wrote:
>>
>> [case1] Code phishing + cut-n-paste attack <>
>> [case1a] through BadAS to GoodAS redirect
>> [case1b] through tampering the unprotected client access res
On 23/02/16 07:56, William Denniss wrote:
> I also wonder if the spec could be re-titled and focus on use-case that it
> solves (supporting multiple ASes without using Connect), rather than the
> attack it mitigates. I like that the metadata draft is targeted to solve a
> particular use-case, whi
This sounds fantastic, Daniel. I was only aware of the work by the
researchers from RUB.de about the CSRF attack on OIDC discovery. I'm
reading the paper right now and want to take some time off to study it
in more detail.
Congratulations for doing this,
Vladimir
On 23/02/16 12:28, Daniel Fett w
Hi Valdimir,
this is exactly what we did in our research paper. We also analyzed and
established a proof of security for one of the proposed mitigations.
Of course, any proof always depends on some assumptions (e.g., no
untrusted third-party code on RP's web site) and aims at specific
security pr
Hi Mike,
You mention that you spent considerable time in research. I wonder if
there is existing theory, in communications or information theory, that
can be used to formally establish and prove (or disprove) the security
of the proposed OAuth measures? Perhaps some work that is totally
unrelated
hi,
FWIW I also find Option A easier to understand/implement.
regards
antonio
On Feb 19, 2016, at 8:42 PM, Hannes Tschofenig
wrote:
> Early February I posted a mail to the list to make progress on the
> solution to the OAuth Authorization Server Mix-Up problem discovered
> late last year.
>
14 matches
Mail list logo
