Torsten,
I'm not tracking how cookies are relevant to the discussion. I'm guessing
that's because we're not on the same page regarding use cases, so allow me to
clearly state mine:
The use case I am concerned with is requests between services where end-to-end
TLS cannot be guaranteed. For exam
Hi Pedram,
I understand why a client would need to allow use of multiple authorization
servers if the client needs to access various resource servers each of which
may trust different ASs (e.g. the client supports accessing resources at
multiple cloud storage services).
However, how common is
Hi Pedram,
Thanks for confirming that the scenario is as I was trying to understand
it. I don't think it's universal that all clients will give transitive
access from the user to the accessed resource, though it's certainly
common; the lack of exposition on that point is what I had been stumbling
No problem. You are always welcome.
> Am 26.11.2019 um 14:07 schrieb Robache Hervé :
>
> Thanks Torsten, I didn't notice this point in CIBA.
>
> Sorry about asking a so silly question.
>
> Hervé
>
> -Message d'origine-
> De : Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Envo
Hi Ben,
The attacker uses the (honest) client shown in Figure 4 as a regular
user. For example, the client might provide access to a cloud storage
via its website, i.e., by using the clients' website, a user can access
her files stored at the resource server.
I'll try to clarify the attack w
Hi Pedram,
On Thu, Nov 21, 2019 at 02:50:52PM +0100, Pedram Hosseyni wrote:
>
> Also, for this or the next version of this document, the Cuckoo's Token
> attack (see Section IV-A of http://arxiv.org/abs/1901.11520/ ), should
> be addressed. We also discussed this issue extensively at the last O
Hi Karsten,
Very interesting observation!
My gut feeling is that this is the real problem here:
Am 26.11.19 um 14:24 schrieb Karsten Meyer zu Selhausen:
> Depending on its implementation the client might simply extract all data
> contained in the Client Information Response and use it for
> auth
Hi,
we identified a possible issue regarding the Mix-Up attack
countermeasures described in the Security Best Current Practices.
Section 4.4.2 of the latest version of the BCP lists "AS-specific
redirect URIs" as a countermeasure for Mix-Up attacks.
This countermeasure can be bypassed if Dynamic
Thanks Torsten, I didn't notice this point in CIBA.
Sorry about asking a so silly question.
Hervé
-Message d'origine-
De : Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Envoyé : mardi 26 novembre 2019 11:33
À : Robache Hervé
Cc : Joseph Heenan; oauth@ietf.org
Objet : Re: [OAUTH-WG
Moving the discussions to an appendix sounds good.
> On 26. Nov 2019, at 08:17, Daniel Fett wrote:
>
> Am 25.11.19 um 23:02 schrieb Torsten Lodderstedt:
>> Parts of the text in section 4 capture discussions of potential solutions
>> and reasons why we decided in favor of a certain solution. I t
Hi Hervé,
the flow you outline is equivalent to CIBA
(https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0-ID1.html).
RFC8628/device grant type and CIBA differ as follows:
- RFC8628 provides the client with an URL for the authorisation process
- CIBA requires t
> On 26 Nov 2019, at 00:10, Richard Backman, Annabelle
> wrote:
>
> > A client can receive a macaroon and use it like a pure bearer token if they
> > want.
> In which case it’s not sender constrained, and no different than any other
> symmetrically encrypted or HMAC’d bearer token.
Yes, that
12 matches
Mail list logo
