+1
I also think PKCE is currently the simplest way to protect OAuth clients from
injection.
Sent by MailWise – See your emails as clean, short chats.
Originalnachricht
Betreff: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even
overHTTPS
Von: William Denniss
An:
lue, and b) the
>client didn't invalidate the value after first use in step 1.
>
>
>> Am 23.04.2016 um 15:53 schrieb Thomas Broyer:
>>
>>
>>
>> On Sat, Apr 23, 2016 at 12:57 PM Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>>
&
Hi Daniel,
how is the attackers supposed to utilise the leaked state value? I would assume
the legit client binds it to a certain user agent, e.g. via the session
context, which is not available to the attacker.
best regards,
Torsten.
Originalnachricht
Betreff: Re: [OAUTH-WG]
Different people, different perceptions :-)
But anyway, the discussion on the list has already started, right?
Originalnachricht
Betreff: Re: [OAUTH-WG] Meeting Minutes
Von: Hannes Tschofenig
An: Brian Campbell ,Torsten Lodderstedt
Cc: oauth@ietf.org
>Hi Torsten,
>
>On 04/19
And what about code injection and open redirectors? I think we already have a
lot of deployment experience that should be used to evolve the spec.
Sent by MailWise – See your emails as clean, short chats.
Originalnachricht
Betreff: Re: [OAUTH-WG] OAuth 2.1
Von: "Phil Hunt (IDM)
Hi Brian,
I assume resource server ids or URIs to be a names namespace for scope values
or that scope values are be bound to certain resource servers. It seems you
have less coupling in mind?
Best regards,
Torsten.
Sent by MailWise – See your emails as clean, short chats.
Originalnac
+1
Sent by MailWise – See your emails as clean, short chats.
Originalnachricht
Betreff: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
Von: Justin Richer
An: George Fletcher
Cc: ""
>+1 for “OAuth 2.0 Authorization Server Discovery”
>
> — Justin
>
>> On Feb 25, 2016, at 2:20 PM,
Cc: <mailto:oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values:
>> Call for Adoption Finalized
>>
>> Can we just do that, then? Seems to be the easiest way to address
>> various needs and concerns.
>>
>> —
even for values
>first defined in non-RFC specifications. This specification is one example of
>doing this.
>
> -- Mike
>
>From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of
>tors...@lodderstedt.net
>Sent: Satur
ethod Reference Values: Call for
Adoption Finalized
Von: John Bradley
An: tors...@lodderstedt.net
Cc: roland.hedb...@umu.se,oauth@ietf.org
>This is not a issue between oauth and OIDC.
>
>This has to do with the registry for JWT being in OAuth. Many protocols that
>use JWT are going to
I basically support adoption of this document. Asserting authentication methods
in access tokens (in this case in JWTS format) is reasonable. We use it to pass
information about the authentication performed prior issuing an access token to
the _resource_ server.
What worries me is the back and
11 matches
Mail list logo
