They are meant to be appositives, (not trying to be condescending, if you are unfamiliar with the english grammar term), except instead of inlined with commas, they use parentheses. Grammatically, the paragraph could have been rewritten as
For example, an end-user, resource owner, can grant a printing service, client, access to her protected photos stored at a photo- sharing service, resource server, without sharing her username and password with the printing service. Instead, she authenticates directly with a server trusted by the photo-sharing service, authorization server, which issues the printing service delegation- specific credentials, access token. If it was written that way instead, would it have been clearer? Personally I don't think it would be, but maybe I'm in the minority. *resource server* follows *photo-sharing service*, because *resource server* is the oauth 2 concept *resource server* entity that is being exemplified by the concrete scenario represented by the *photo-sharing service*. The photo-sharing service in this example is* the resource service, *from an OAuth perspective. Just like the server that the photo-sharing service trusts, is called *an authorization server*. The example exists to explain using a real world scenario these core entities in the OAuth paradigm. On Sun, Sep 17, 2023 at 1:24 PM <w.fas...@gmail.com> wrote: > I'm especially confused by why 'photo-sharing service' is followed by > '(resource server)' in parentheses the first time and '(authorization > server)' in parentheses the second time. > > > > > > -- > > Wilhelm > > > > *Von:* Warren Parad <wpa...@rhosys.ch> > *Gesendet:* 17 September 2023 12:51 > *An:* Aaron Parecki <aaron=40parecki....@dmarc.ietf.org> > *Cc:* RFC Errata System <rfc-edi...@rfc-editor.org>; w.fas...@gmail.com; > oauth@ietf.org > *Betreff:* Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7642) > > > > It does look confusing if we only look at that one sentence, but as soon > as you pull in the whole paragraph, it seems pretty clear > > > > https://www.rfc-editor.org/rfc/rfc6749 > > For example, an end-user (resource owner) can grant a printing > service (client) access to her protected photos stored at a photo- > sharing service (resource server), without sharing her username and > password with the printing service. Instead, she authenticates > directly with a server trusted by the photo-sharing service > (authorization server), which issues the printing service delegation- > specific credentials (access token). > > > > Arguably the only improvement here would be to outline the full case, by > adding something like: > > The printing service (client) uses the credentials (access token) to > access the photo-sharing service (resource server), by sending the > credentials to the server. When receiving the credentials (access token), > the photo-sharing service (resource server) verifies the credentials using > the trusted server (authorization server). > > > > But I think that's wholly unnecessary, since everything has been defined > in this case. You can't mistake the resource server for the authorization > server, because the resource server has already been defined to be the > *photo-sharing > service.* That means the *(authorization server)* identification > appositive can only apply to the trusted server. The errata breaks the > pattern of the paragraph and introduces confusion because it fails to > define the terms authorization server and access token, which arguably is > the whole point of the example. > > > > On Sun, Sep 17, 2023 at 12:35 PM Aaron Parecki <aaron= > 40parecki....@dmarc.ietf.org> wrote: > > I disagree with this errata. The original text is correctly representing > that the "photo-sharing service" trusts the authorization server. The > suggested text is ambiguous because it does not make clear which party is > trusting which other party. > > > > Aaron > > > > On Sun, Sep 17, 2023 at 11:00 AM RFC Errata System < > rfc-edi...@rfc-editor.org> wrote: > > The following errata report has been submitted for RFC6749, > "The OAuth 2.0 Authorization Framework". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7642 > > -------------------------------------- > Type: Editorial > Reported by: Wilhelm Fast <w.fas...@gmail.com> > > Section: 1 > > Original Text > ------------- > Instead, she authenticates directly with a server trusted by the > photo-sharing service (authorization server), which issues the printing > service delegation- > specific credentials (access token). > > Corrected Text > -------------- > Instead, she directly authenticates with a trusted server, the > authorization server, which issues delegation-specific credentials, known > as access tokens, to the printing service for controlled and secure access. > > Notes > ----- > The sentence is confusing, and the reader might confuse the Authorization > Server with the Resource Server. > > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
