The term resource owner in the spec is a bit strange but well defined in the
front matter of the spec.
resource owner
An entity capable of granting access to a protected resource.
When the resource owner is a person, it is referred to as an
end-user.
The individual using the client, and granting access to the resource is by
definition the resource owner.
It is true that there may be other resource owners of the same resource and
perhaps some business process that is also responsible for granting the scope
to the end-user’s client.
The point of trisection is the ability of the client to maintain the
confidentiality of its credential.
I don’t think this proposed change is an improvement as proposed.
Perhaps I am missing the authors intent.
Regards
John B.
> On Jan 12, 2018, at 8:56 AM, RFC Errata System <[email protected]>
> wrote:
>
> 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/eid5234
>
> --------------------------------------
> Type: Technical
> Reported by: Randip Kumar Malakar <[email protected]>
>
> Section: 2.1.
>
> Original Text
> -------------
> public
> Clients incapable of maintaining the confidentiality of their
> credentials (e.g., clients executing on the device used by the
> resource owner, such as an installed native application or a web
> browser-based application), and incapable of secure client
> authentication via any other means.
>
> Corrected Text
> --------------
> public
> Clients incapable of maintaining the confidentiality of their
> credentials (e.g., clients executing on the device used by the
> third-party (not resource owner but another end user), such as an
> installed native application or a web
> browser-based application), and incapable of secure client
> authentication via any other means.
>
> Notes
> -----
> I think in case of public client type, it should state as "e.g. the clients
> executing on the device used by third-party and not the actual resource
> owner" as mentioned in the original RFC. I let the author or experts to
> review my remark. Thanks.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6749 (draft-ietf-oauth-v2-31)
> --------------------------------------
> Title : The OAuth 2.0 Authorization Framework
> Publication Date : October 2012
> Author(s) : D. Hardt, Ed.
> Category : PROPOSED STANDARD
> Source : Web Authorization Protocol
> Area : Security
> Stream : IETF
> Verifying Party : IESG
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
