Hi all,
I couldn't understand why "their" became "the third party's" in the diff
between draft31 and RFC6749 below.
===
Resource owners cannot revoke access to an individual third-party third party
without revoking access to all third-parties, third parties, and must do so by
changing their the
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 : Token Revocation
Author(s) : Torsten Lodderstedt
Stefanie Dron
Hi,
the new revision is based on the WGLC feedback and incorporates the
following changes:
- renamed "access grant" to "authorization" and reworded parts of
Abstract and Intro in order to better align with core spec wording
(feedback by Amanda)
- improved formatting of section 2.1. (feedbac
I believe you're correct, Nov, and that this was potentially a mistake
from the RFC editor. That sentence *should* be talking about the
resource owner's password.
-- Justin
On 01/07/2013 06:53 AM, nov matake wrote:
Hi all,
I couldn't understand why "their" became "the third party's" in the
Hi George,
thank you for pointing this out. Your proposal sounds reasonable
although the revocation spec does not build on top of RFC 6750.
As refering to RFC 6750 would create a new dependency, one could also
argue it would be more robust to leave both specs separated.
What do others think
My concern with leaving both specs separated is that over time the
semantics of the two error codes could diverge and that would be
confusing for developers. If we don't want to create a dependency on RFC
6750, then I would recommend a change to the error code name so that
there is no name coll
Is "authorization" the best choice here over "access grant" since it's really
not authorization that is being revoked it's the grant
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Monday, January 7, 2013 4:08 AM
To:
Access grant might be the better term. That's why previous revisions used it.
But as Amanda correctly pointed out, the core spec does not define a concept of
an access grant. There is just the term authorization implicitly introduced via
other definitions.
section 1.3 introduces authorization g
"Access grant" was the old term that Eran came up with, and it has been
replaced by "authorization grant", which I agree is also not as well
defined as it could be. Both of these refer to the conceptual act of the
resource owner saying "it is OK for this client to do these things". I
objected t
+1 for using the same terminology as OAuth Core and Bearer
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Monday, January 07, 2013 11:36 AM
To: Torsten Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.
But what is the same terminology? Authorization grant? I think 1.3 defines the
authorization grant as an external representation of the authorization, not the
authorization itself.
Am 07.01.2013 um 21:12 schrieb Mike Jones :
> +1 for using the same terminology as OAuth Core and Bearer
>
> Fr
A new Request for Comments is now available in online RFC libraries.
RFC 6819
Title: OAuth 2.0 Threat Model and
Security Considerations
Author: T. Lodderstedt, Ed.,
M. McGloin,
P. Hunt
The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".
--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3446
--
Type: Editorial
Thanks Justin,
I reported this errata at RFC errata report page.
On 2013/01/08, at 0:00, Justin Richer wrote:
> I believe you're correct, Nov, and that this was potentially a mistake from
> the RFC editor. That sentence *should* be talking about the resource owner's
> password.
>
> -- Justi
> Corrected Text
> --
> Resource owners cannot revoke access to an individual third party without
> revoking access
> to all third parties, and must do so by changing their password.
>
> Notes
> -
> The text was originally "their" but changed to "the third party's" between
> the l
15 matches
Mail list logo