Re: [OAUTH-WG] OAuth Digest, Vol 181, Issue 55

شكرا لكم من اعماق قلبي ارجو منكم استعادة المال الذي تم سحبة الى هذا العنوان
هذا عنوان الهاكرز
 0x9696f59E4d72E237BE84fFD425DCaD154Bf96976

في الأربعاء، ٢٩ نوفمبر ٢٠٢٣, ١٠:١٢ م <oauth-request@ietf.org> كتب:

> Send OAuth mailing list submissions to
>         oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         oauth-request@ietf.org
>
> You can reach the person managing the list at
>         oauth-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>    1. I-D Action: draft-ietf-oauth-transaction-tokens-00.txt
>       (internet-drafts@ietf.org)
>    2. Re: [Editorial Errata Reported] RFC6749 (7715) (Brian Campbell)
>    3. Re: [Editorial Errata Reported] RFC6749 (7716) (Brian Campbell)
>    4. Re: [Editorial Errata Reported] RFC6749 (7715)
>       (Rebecca VanRheenen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 29 Nov 2023 10:12:44 -0800
> From: internet-drafts@ietf.org
> To: <i-d-announce@ietf.org>
> Cc: oauth@ietf.org
> Subject: [OAUTH-WG] I-D Action:
>         draft-ietf-oauth-transaction-tokens-00.txt
> Message-ID: <170128156401.30455.17043866146370716999@ietfa.amsl.com>
> Content-Type: text/plain; charset="utf-8"
>
> Internet-Draft draft-ietf-oauth-transaction-tokens-00.txt is now
> available. It
> is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.
>
>    Title:   Transaction Tokens
>    Authors: Atul Tulshibagwale
>             George Fletcher
>             Pieter Kasselman
>    Name:    draft-ietf-oauth-transaction-tokens-00.txt
>    Pages:   19
>    Dates:   2023-11-29
>
> Abstract:
>
>    Transaction Tokens (Txn-Tokens) enable workloads in a trusted domain
>    to ensure that user identity and authorization context of an external
>    programmatic request, such as an API invocation, are preserved and
>    available to all workloads that are invoked as part of processing
>    such a request.  Txn-Tokens also enable workloads within the trusted
>    domain to optionally immutably assert to downstream workloads that
>    they were invoked in the call chain of the request.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/
>
> There is also an HTMLized version available at:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-00
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 29 Nov 2023 11:35:54 -0700
> From: Brian Campbell <bcampbell@pingidentity.com>
> To: Aaron Parecki <aaron=40parecki.com@dmarc.ietf.org>
> Cc: RFC Errata System <rfc-editor@rfc-editor.org>,
>         hello@alexwilson.io, oauth@ietf.org
> Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7715)
> Message-ID:
>         <CA+k3eCRagYgHaKH8uNJ=
> iJ3jtK4zHmNSf9orzgC15LpruSJ1Jw@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Agree with Aaron that this errata should be rejected.
>
> On Wed, Nov 29, 2023 at 10:57?AM Aaron Parecki <aaron=
> 40parecki.com@dmarc.ietf.org> wrote:
>
> > This errata should be rejected, as section 4.2.2.1 is about the implicit
> > flow, which returns parameters in the fragment part of the URL, not query
> > parameters.
> >
> >
> > On Wed, Nov 29, 2023 at 11:51?AM RFC Errata System <
> > rfc-editor@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/eid7715
> >>
> >> --------------------------------------
> >> Type: Editorial
> >> Reported by: Alex Wilson <hello@alexwilson.io>
> >>
> >> Section: 4.2.2.1
> >>
> >> Original Text
> >> -------------
> >>
> >>    HTTP/1.1 302 Found
> >>    Location:
> https://client.example.com/cb#error=access_denied&state=xyz
> >>
> >> Corrected Text
> >> --------------
> >>
> >>    HTTP/1.1 302 Found
> >>    Location:
> https://client.example.com/cb?error=access_denied&state=xyz
> >>
> >> Notes
> >> -----
> >> For query parameters, the hash should be a question mark.
> >>
> >> Instructions:
> >> -------------
> >> This erratum is currently posted as "Reported". (If it is spam, it
> >> will be removed shortly by the RFC Production Center.) Please
> >> use "Reply All" to discuss whether it should be verified or
> >> rejected. When a decision is reached, the verifying party
> >> will 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
> >
>
> --
> _CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.? If you have
> received this communication in error, please notify the sender immediately
> by e-mail and delete the message and any file attachments from your
> computer. Thank you._
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20231129/97b4ee79/attachment.htm
> >
>
> ------------------------------
>
> Message: 3
> Date: Wed, 29 Nov 2023 11:41:17 -0700
> From: Brian Campbell <bcampbell@pingidentity.com>
> To: RFC Errata System <rfc-editor@rfc-editor.org>
> Cc: hello@alexwilson.io, oauth@ietf.org
> Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7716)
> Message-ID:
>         <CA+k3eCSV3B-KMePQtRKvO1=
> NsK074TZz+EGq_BWt-sR374DKuw@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> This errata should also be rejected for reasons similar to
> https://www.rfc-editor.org/errata/eid7715 - section 4.2.2 is about the
> implicit flow, which returns parameters in the fragment part of the URL,
> not query parameters. And that kind of consistency of hostname values in
> examples does not warrant an errata.
>
>
>
>
> On Wed, Nov 29, 2023 at 9:56?AM RFC Errata System <
> rfc-editor@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/eid7716
> >
> > --------------------------------------
> > Type: Editorial
> > Reported by: Alex Wilson <hello@alexwilson.io>
> >
> > Section: 4.2.2
> >
> > Original Text
> > -------------
> >    For example, the authorization server redirects the user-agent by
> >    sending the following HTTP response (with extra line breaks for
> >    display purposes only):
> >
> >      HTTP/1.1 302 Found
> >      Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
> >                &state=xyz&token_type=example&expires_in=3600
> >
> >
> > Corrected Text
> > --------------
> >    For example, the authorization server redirects the user-agent by
> >    sending the following HTTP response (with extra line breaks for
> >    display purposes only):
> >
> >      HTTP/1.1 302 Found
> >      Location:
> > http://client.example.com/cb?access_token=2YotnFZFEjr1zCsicMWpAA
> >                &state=xyz&token_type=example&expires_in=3600
> >
> >
> > Notes
> > -----
> > - Host example.com should be client.example.com to be consistent with
> > other examples.
> > - A hash is used for the query parameters when a question mark should
> have
> > been used.
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". (If it is spam, it
> > will be removed shortly by the RFC Production Center.) Please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > will 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
> >
>
> --
> _CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.? If you have
> received this communication in error, please notify the sender immediately
> by e-mail and delete the message and any file attachments from your
> computer. Thank you._
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20231129/dbb1076d/attachment.htm
> >
>
> ------------------------------
>
> Message: 4
> Date: Wed, 29 Nov 2023 11:12:16 -0800
> From: Rebecca VanRheenen <rvanrheenen@amsl.com>
> To: Roman Danyliw <rdd@cert.org>
> Cc: hello@alexwilson.io, dick.hardt@gmail.com, oauth@ietf.org, RFC
>         Editor <rfc-editor@rfc-editor.org>
> Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7715)
> Message-ID: <0E8810F4-55E6-42BD-A170-392D2F0742BC@amsl.com>
> Content-Type: text/plain;       charset=utf-8
>
> Hi Roman,
>
> We are unable to verify this erratum that the submitter marked as
> editorial. Please note that we have changed the ?Type? of the following
> errata report to ?Technical?.  As Stream Approver, please review and set
> the Status and Type accordingly (see the definitions at
> https://www.rfc-editor.org/errata-definitions/).
>
> You may review the report at:
> https://www.rfc-editor.org/errata/eid7715
>
> Please see https://www.rfc-editor.org/how-to-verify/ for further
> information on how to verify errata reports.
>
> Further information on errata can be found at:
> https://www.rfc-editor.org/errata.php
>
> Thank you.
>
> RFC Editor/rv
>
>
> > On Nov 29, 2023, at 8:51 AM, RFC Errata System <
> rfc-editor@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/eid7715
> >
> > --------------------------------------
> > Type: Editorial
> > Reported by: Alex Wilson <hello@alexwilson.io>
> >
> > Section: 4.2.2.1
> >
> > Original Text
> > -------------
> >
> >   HTTP/1.1 302 Found
> >   Location: https://client.example.com/cb#error=access_denied&state=xyz
> >
> > Corrected Text
> > --------------
> >
> >   HTTP/1.1 302 Found
> >   Location: https://client.example.com/cb?error=access_denied&state=xyz
> >
> > Notes
> > -----
> > For query parameters, the hash should be a question mark.
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". (If it is spam, it
> > will be removed shortly by the RFC Production Center.) Please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > will 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
> >
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 181, Issue 55
> **************************************
>