[OAUTH-WG] Question on diff between draft31 and RFC6749

2013-01-07 Thread nov matake
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

[OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

2013-01-07 Thread internet-drafts
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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

2013-01-07 Thread Torsten Lodderstedt
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

Re: [OAUTH-WG] Question on diff between draft31 and RFC6749

2013-01-07 Thread Justin Richer
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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

2013-01-07 Thread Torsten Lodderstedt
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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

2013-01-07 Thread George Fletcher
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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

2013-01-07 Thread Anthony Nadalin
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:

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

2013-01-07 Thread Torsten Lodderstedt
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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

2013-01-07 Thread Justin Richer
"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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

2013-01-07 Thread Mike Jones
+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.

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

2013-01-07 Thread Torsten Lodderstedt
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

[OAUTH-WG] RFC 6819 on OAuth 2.0 Threat Model and Security Considerations

2013-01-07 Thread rfc-editor
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

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (3446)

2013-01-07 Thread RFC Errata System
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

Re: [OAUTH-WG] Question on diff between draft31 and RFC6749

2013-01-07 Thread nov matake
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

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (3446)

2013-01-07 Thread Barry Leiba
> 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