I'm not sure normative language even fits here. We need something like
"Authorization codes should be treated as sensitive and the client needs
to try to make sure it doesn't leak the authorization code." But more
formal and less garden pathy than I'm able to pen at the moment.
-- Justin
On
Published draft-ietf-oauth-v2-18.
This was a much larger effort than I was previously expecting or planning.
Review requires reading the full text as the number of changes makes using a
diff tool impractical. Below is the mostly complete list of changes. The new
draft should include very few no
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Authorization Protocol
Author(s) : Eran Hammer-Lahav
Please ignore. This was a bad submission (wrong file). -18 will follow shortly.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of internet-dra...@ietf.org
> Sent: Friday, July 08, 2011 11:55 AM
> To: i-d-annou...@ietf.org
> Cc: oauth@ie
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Authorization Protocol
Author(s) : Eran Hammer-Lahav
Can you provide this in a form suitable for pasting into the current text?
Browser same origin policy is enforced by the user-agent, and is beyond the
scope of this protocol.
EHL
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Friday, July 08, 2011 11:52 AM
>
On Fri, Jul 8, 2011 at 11:39 AM, Eran Hammer-Lahav wrote:
> How exactly? They are not confidential by nature, being received via
> redirection in the URI query. I know what this sentence is trying to
> accomplish but not sure how to do that with normative language. SHOULD
> doesn't really work
"Authorization codes MUST be kept confidential"
How exactly? They are not confidential by nature, being received via
redirection in the URI query. I know what this sentence is trying to accomplish
but not sure how to do that with normative language. SHOULD doesn't really work
here either.
Sugg
"the authorization server SHOULD deploy other means to detect refresh token
abuse"
This requires an example.
EHL
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
FYI and feedback welcome.
- Forwarded Message -
From: William J. Mills
To: "kit...@ietf.org"
Cc: Hannes Tschofenig ; "hannes.tschofe...@gmx.net"
; Tim Showalter
Sent: Thursday, July 7, 2011 11:52 AM
Subject: New draft of https://tools.ietf.org/htmdraft-mills-kitten-sasl-oauth
Hi,
I
The security of the protocol relies fully (implicit grant) or partially
(authorization code) on the validation of the redirection URI. This was well
understood by many experts but until -17, we largely ignored by the
specification.
Using dynamic values are still fully supported:
3.1.2.2. R
Hey Torsten,
The provided text and alternative text are just not helpful. If I am unable to
understand it, I have doubt other readers will be able to.
I don't know what you mean by 'other means' which are not already described in
the document (based on -17). Referencing the security thread mode
Hi Brian,
your text is definitely a valuable contribution. Please note: your earlier text
on OAuth security considerations has already been incorporated into the
security document.
I would suggest to first incorporate your new text there (probably together
with your proposal regarding redirec
Hi Eran,
including dynamic values within redirect uris is standard practice today and is
allowed by the spec's text so far. I don't mind to change it but the restricted
behavior you prefer is a significant protocol change.
Moreover, I would like to understand the threat you have in mind and inc
seems you are contradicting yourself.
You criticised the MUST and suggested to include some examples. I bought into
your argument and suggested to refer to the security doc for examples and
additional explanations. That's what this document is intended for, to provide
background beyond what we
15 matches
Mail list logo
