Re: [OAUTH-WG] Transaction Tokens issuance in the absence of incoming token

One potential benefit of keeping the use of Token Exchange is that some AS products/implementations have built a fair amount of configurability and extensibility into their Token Exchange support, which might allow for existing systems to be set up to do Transaction Tokens. Whereas a new endpoint

Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata

thing like that jwks_uri metadata parameter seems well enough defined and isn't being questioned in this thread anyway so needn't be defended or explained. On Wed, Apr 3, 2024 at 3:00 PM Brian Campbell wrote: > > > On Wed, Apr 3, 2024 at 9:52 AM Michael Jones > wrote: > >

Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata

eaningful or interoperability improving way. Absent that though, I guess I would argue for their removal. > > -- Mike > > > > *From:* OAuth *On Behalf Of *Brian Campbell > *Sent:* Tuesday, April 2, 2024 2:45 PM > *To:* Vladimir Dzhuvinov > *Cc:* oauth@i

Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata

I've had questions similar to Vladimir's* and do still think that some additional context or clarification or something in the document would be helpful. * https://mailarchive.ietf.org/arch/msg/oauth/LA6sqNOV98D7wP44p2Hl6dpSmtg/ On Thu, Mar 28, 2024 at 2:57 PM Vladimir Dzhuvinov wrote: > I

Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata

On Fri, Mar 29, 2024 at 10:46 PM Michael Jones wrote: > Thanks again for the detailed review, Atul! I’ve updated the PR > accordingly. Responses are inline below… > > > > *From:* OAuth *On Behalf Of *Atul Tulshibagwale > *Sent:* Friday, March 29, 2024 6:31 PM > *To:* Rifaat Shekh-Yusef ;

Re: [OAUTH-WG] For review/discussion: Cedar profile of OAuth Rich Authorization Requests

ication of intent is not important, we're happy to just specify > the content the type parameter and define a new policySet parameter, or > possibly just give guidance to put a policy set within "privileges." > > > Sarah Cecchetti > > > -- >

Re: [OAUTH-WG] For review/discussion: Cedar profile of OAuth Rich Authorization Requests

I'm inferring some intent (apologies if I've got it wrong!) but I think it'd make the most sense for this work to start with defining a RAR type value (something like "https://cedarpolicy.com;) and define that type as having the "policySet" parameter. An updated example figure 1 from the draft

Re: [OAUTH-WG] Updating "Identity Chaining across Trust Domains" draft name

(a few days later than promised) the name has been updated and the new draft revision published https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/01/. A listing of other changes copied from https://www.ietf.org/archive/id/draft-ietf-oauth-identity-chaining-01.html#appendix-D-2 is

Re: [OAUTH-WG] About: "Rewrite unlinkability considerations" #354

I'm not sure what the issue is but it appears commenting on the pull request is possible because your comment shows up (twice even). That said, I believe the sentiment of your suggestions here are already in the content of the PR but just organized/expressed somewhat differently (in a style more

Re: [OAUTH-WG] [Technical Errata Reported] RFC8414 (7793)

This erratum seems legit. On Wed, Jan 31, 2024 at 2:46 PM RFC Errata System wrote: > The following errata report has been submitted for RFC8414, > "OAuth 2.0 Authorization Server Metadata". > > -- > You may review the report below and at: >

Re: [OAUTH-WG] client_id in CWT Claims

It took a bit of looking but Neil is correct and that some other document is RFC9200: https://datatracker.ietf.org/doc/html/rfc9200#name-cbor-web-token-claims (last one in that section) which doesn't seem quite right. I would have expected the entry in the registry to point back to RFC9200,

Re: [OAUTH-WG] [Technical Errata Reported] RFC7519 (7720)

I agree that the change in text is too much for an errata. But I am sympathetic to the problem that the reporter has described. Perhaps it'd be appropriate as an errata that, in the interest of interoperability, mentions/reminds that 'iat' doesn't have defined semantics about rejection and

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

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

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

Agree with Aaron that this errata should be rejected. On Wed, Nov 29, 2023 at 10:57 AM Aaron Parecki 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,

Re: [OAUTH-WG] Call for adoption - Identity Chaining

I support adoption. On Tue, Nov 14, 2023 at 5:59 AM Rifaat Shekh-Yusef wrote: > All, > > This is an *official* call for adoption for the *Identity Chaining *draft: > > https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/ > > Please, reply on the mailing list and let

Re: [OAUTH-WG] Updated "OAuth for First-Party Apps" draft

I read through the draft while doing some prep for the meetings this week (which I'm attending remotely). While I have reservations about the idea of the WG taking on and endorsing the work, I did have some comments/suggestions on the general content of the draft that hopefully will be useful

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

suggestions inline below. > > On 27 Oct 2023, at 00:26, Brian Campbell > wrote: > > Thanks Neil! Appreciate the productive discussion. Some more responses > below (while also attempting to snip out and declutter the message). > > On Thu, Oct 26, 2023 at 7:03 AM Neil Madden &

Re: [OAUTH-WG] Relationship between SPICE and OAuth

I didn't expect to see SD-JWT as a "proposed work item" on the SPICE BoF agenda because its appropriateness to be and stay in the OAuth WG had been discussed on list (e.g., https://mailarchive.ietf.org/arch/msg/oauth/6qjAsqLwyp5WoxqY3dVv8SJ5nVM/) and SD-JWT wasn't mentioned in the SPICE BoF

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

On Thu, Oct 26, 2023 at 5:26 PM Brian Campbell wrote: > > I think you might underestimate the difficulty in > creating/changing/establishing such a registry and overestimate its > effectiveness and usefulness. And I think the selective disclosability > treatment of many claim

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

Thanks Neil! Appreciate the productive discussion. Some more responses below (while also attempting to snip out and declutter the message). On Thu, Oct 26, 2023 at 7:03 AM Neil Madden wrote: On 25 Oct 2023, at 22:00, Brian Campbell wrote: > > The draft currently says that second-pr

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

rg/arch/msg/oauth/NOPT1WNtvMvlygLaZH7YvLFVpKo/ > [2]: > https://www.cnet.com/news/privacy/web-browser-flaw-could-put-e-commerce-security-at-risk/ > [3]: https://en.wikipedia.org/wiki/Commitment_scheme > > On 23 Oct 2023, at 17:17, internet-dra...@ietf.org wrote: > > Internet-Draft draf

Re: [OAUTH-WG] Clarification on SD-JWT verification

Agree that it should be clarified. Being precise with language around this stuff is tricky. But my understanding of the intent was to ensure that no digest value is repeated in the whole of the SD-JWT - either in the payload directly or recursively in any Disclosure. Because of the trickiness of

Re: [OAUTH-WG] SD-JWT explicit guidance on parsing json strings

That makes sense in principle but is maybe not particularly actionable or helpful guidance. The need to do some JSON parsing/processing prior to signature verification is kinda inherent to JWS itself. At a minimum the algorithm is in the header. And as you note, a key id or similar might also be

Re: [OAUTH-WG] OAuth and JWT/VC documents

If I might offer an observation... The draft-looker-oauth-jwt-cwt-status-list draft is (or can easily be[*]) really just a generic status/revocation checking mechanism for JWTs in general. Given the history/lineage of JWT development within the OAuth WG, it seems like a general JWT

Re: [OAUTH-WG] [Editorial Errata Reported] RFC9449 (7646)

Agree, this errata report looks correct. On Mon, Sep 18, 2023 at 1:27 AM Daniel Fett wrote: > The erratum looks correct to me. > > -Daniel > Am 18.09.23 um 08:57 schrieb RFC Errata System: > > The following errata report has been submitted for RFC9449, > "OAuth 2.0 Demonstrating Proof of

Re: [OAUTH-WG] OAuth and JWT/VC documents

Hi Roman, I'm going to dodge some of the bigger picture questions but wanted to give a bit of historical context/justification for the draft-ietf-oauth-selective-disclosure-jwt work in the OAuth WG. JWT itself was a product of OAuth WG yet was

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

I did have a few unanswered comments/questions on the draft https://mailarchive.ietf.org/arch/msg/oauth/LA6sqNOV98D7wP44p2Hl6dpSmtg/ that hopefully can be addressed as it progresses. On Wed, Sep 6, 2023 at 5:50 AM Rifaat Shekh-Yusef wrote: > All, > > Based on the responses on this thread, we

[OAUTH-WG] Fwd: Last Call: (Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect) to Proposed Standard

I just happened to notice this and given the title of the draft, "Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect" thought it might be of interest to some in the OIDC or OAuth working groups (both cc'd). I don't have the cycles (or energy to be

Re: [OAUTH-WG] Call for adoption - Attestation-Based Client Authentication

I am in favor of adoption. On Sat, Jul 29, 2023, 1:27 PM Rifaat Shekh-Yusef wrote: > All, > > This is an official call for adoption for the *Attestation-Based Client > Authentication *draft discussed in SF. > > https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/ >

Re: [OAUTH-WG] Call for adoption - SD-JWT-based Verifiable Credentials

+1 On Sat, Jul 29, 2023, 1:37 PM Michael Prorock wrote: > I support adoption - but would request that if a group dedicated to > verifiable credentials is created prior to this draft being finalized, that > the group consider moving this draft to that group. > > Mike Prorock > CTO - mesur.io > >

Re: [OAUTH-WG] OAuth 2.0 Protected Resource Metadata now with WWW-Authenticate

This certainly isn't a comprehensive review or endorsement necessarily but I read though the latest draft and had a couple of off-the-cuff* comments/questions: The abstract and intro talk only about enabling clients to obtain information needed to interact with a protected resource. However, the

Re: [OAUTH-WG] RFC 9396 - RAR doubt about examples

I think Torsten did the example with "debtorAccount" so he can maybe provide more insight into what he was trying to convey with it. But I interpreted it similar to Kai in it being more akin to the sub and about the user's account in general rather than the specific transaction. The text "selected

Re: [OAUTH-WG] draft-ietf-oauth-rar use of “WWW-Authenticate” Response Header

me case when a protected resource needs the rich authorization? > > > > Best regards. > > > > *From: *OAuth on behalf of Brian Campbell > > *Date: *Thursday, 25 May 2023 at 21:30 > *To: *"Oliva Fernandez, Jorge" 40santander.co...@dmarc.ietf.org> > *Cc

Re: [OAUTH-WG] draft-ietf-oauth-rar use of “WWW-Authenticate” Response Header

The thinking was generally that params of WWW-Authenticate Response Header Field weren't a great fit for rich JSON authorization data (both in syntax and semantics). The authorization detail types are really API-specific things, and as a result, it's expected that the methods by which clients

Re: [OAUTH-WG] [Technical Errata Reported] RFC8693 (7511)

Thanks Aaron. I agree with your assessment. On Mon, May 8, 2023 at 10:00 AM Aaron Parecki wrote: > This errata is incorrect and should be rejected. RFC7523 defines two > separate uses of JWTs, one is client authentication and the other is an > authorization grant. When using RFC7523 as client

Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)

Thanks, Murray, for the quick turnaround! On that first SHOULD. The reasons for not prompting the user in that particular example are more about user experience than protocol considerations. Here we avoid the MUST to ensure that those scenarios can be handled without creating bad user

Re: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)

Thank you, Lars, for the review and ballot. I put together this small PR with updates for the comments/nits https://github.com/oauth-wg/oauth-step-up-authn-challenge/pull/4 On Wed, Apr 12, 2023 at 5:18 AM Lars Eggert via Datatracker < nore...@ietf.org> wrote: > Lars Eggert has entered the

Re: [OAUTH-WG] Lars Eggert's Discuss on draft-ietf-oauth-dpop-14: (with DISCUSS and COMMENT)

The smaller comments/nits are addressed in this PR https://github.com/danielfett/draft-dpop/pull/184/files On Wed, Apr 12, 2023 at 6:52 AM Brian Campbell wrote: > Thank you, Lars, for the review. I've endeavored to respond to your > comments, especially the Discuss item, inline below.

Re: [OAUTH-WG] Lars Eggert's Discuss on draft-ietf-oauth-dpop-14: (with DISCUSS and COMMENT)

Thank you, Lars, for the review. I've endeavored to respond to your comments, especially the Discuss item, inline below. And I will soon make corresponding updates to the document source. On Wed, Apr 12, 2023 at 4:03 AM Lars Eggert via Datatracker < nore...@ietf.org> wrote: > Lars Eggert has

Re: [OAUTH-WG] Warren Kumari's No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

Thank you, Warren, for the review and ballot. I've replied inline below and put together this small PR with corresponding edits: https://github.com/danielfett/draft-dpop/pull/183/files On Tue, Apr 11, 2023 at 1:10 PM Warren Kumari via Datatracker < nore...@ietf.org> wrote: > Warren Kumari has

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-selective-disclosure-jwt-04.txt

Fett Kristina Yasuda Brian Campbell Filename: draft-ietf-oauth-selective-disclosure-jwt-04.txt Pages : 70 Date: 2023-04-11 Abstract: This document specifies conventions for creating JSON Web Token (JWT) documents

Re: [OAUTH-WG] Éric Vyncke's No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

Thanks for the review and ballot Éric. I've replied inline below and put together this PR with corresponding edits: https://github.com/danielfett/draft-dpop/pull/182/files On Mon, Apr 10, 2023 at 11:45 PM Éric Vyncke via Datatracker < nore...@ietf.org> wrote: > Éric Vyncke has entered the

Re: [OAUTH-WG] [IANA #1270471] expert review for draft-ietf-oauth-dpop (jwt)

Thanks David, I approve the JWT claims registrations. On Thu, Apr 6, 2023 at 9:39 AM David Dong via RT < drafts-expert-review-comm...@iana.org> wrote: > Dear John, Brian, Michael and Chuck (cc: oauth WG), > > As the designated experts for the JSON Web Token Claims registry, can you > review the

Re: [OAUTH-WG] Httpdir telechat review of draft-ietf-oauth-step-up-authn-challenge-13

r 2023, at 5:31 am, Brian Campbell > wrote: > > And that PR is here > https://github.com/oauth-wg/oauth-step-up-authn-challenge/pull/3/files > > On Wed, Apr 5, 2023 at 10:59 AM Brian Campbell > wrote: > Thank you for the review Mark. I've replied inline below with s

Re: [OAUTH-WG] Httpdir telechat review of draft-ietf-oauth-step-up-authn-challenge-13

And that PR is here https://github.com/oauth-wg/oauth-step-up-authn-challenge/pull/3/files On Wed, Apr 5, 2023 at 10:59 AM Brian Campbell wrote: > Thank you for the review Mark. I've replied inline below with some context > or explanation as best I can. And I'll put togethe

Re: [OAUTH-WG] Httpdir telechat review of draft-ietf-oauth-step-up-authn-challenge-13

Thank you for the review Mark. I've replied inline below with some context or explanation as best I can. And I'll put together a PR with corresponding changes/clarifications. On Tue, Apr 4, 2023 at 11:18 PM Mark Nottingham via Datatracker < nore...@ietf.org> wrote: > Reviewer: Mark Nottingham >

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

I don't know the best language either but very much concur with the sentiment. On Wed, Mar 8, 2023 at 8:36 AM Aaron Parecki wrote: > Since that is my comment referenced in the OpenID thread, I should clarify > that my intent was to have this language in the Security BCP with the > caveat that

Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-step-up-authn-challenge-11

On Wed, Mar 1, 2023 at 5:04 AM Christer Holmberg < christer.holmb...@ericsson.com> wrote: > Hi, > > QMa1: General > > As the document defines a new error code, and define new > WWW-Authenticate parameters, should the document not be an Update > to > RFC 6750? >

Re: [OAUTH-WG] DPoP proof keys, token renewal, and confidential clients

Hi Brock :) The term "credential rotation" there was meant (to me anyway when writing the text) to refer to the client authentication credential - meaning the client config/metadata about its authentication credentials can be updated without invalidating the RT (as is the case already in 'plain'

Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-step-up-authn-challenge-11

Thanks Christer and Vittorio, I've snipped out some unneeded parts of the prior conversation and added my replies to parts inline below. On Tue, Feb 28, 2023 at 5:09 AM Christer Holmberg < christer.holmb...@ericsson.com> wrote: > > >> QMa1: General > >> > >>As the document defines a new

Re: [OAUTH-WG] Review of draft-ietf-oauth-selective-disclosure-jwt-02

Thanks for the review John. I've tried to reply to the comments inline below. On Sun, Jan 29, 2023 at 8:22 AM John Mattsson wrote: > Hi, > > > > The reopened JOSE WG which I am co-chairing has in its charter to sync > with the Selective Disclosure JWT work in Oauth WG. I therefore did a >

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-dpop-12

Thanks for the review Benjamin! Specific replies are inline below. On Fri, Jan 20, 2023 at 2:20 PM Benjamin Schwartz via Datatracker < nore...@ietf.org> wrote: > Reviewer: Benjamin Schwartz > Review result: Ready > > This is a very mature, carefully drafted specification. > Appreciate that.

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-dpop-13.txt

the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) Authors : Daniel Fett Brian Campbell

Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)

Hi Mark, Thanks for the review and feedback. I am aware of HTTP Structured Fields and certainly see value in it - even using it in some other work in which I'm involved. However, I'm unsure of its fit or utility for this draft. With that said, I've tried to reply more specifically to your

Re: [OAUTH-WG] Small bug in DPoP 12

Thanks Dominick, I believe they should both use HTTP because that claim and check is about something from HTTP semantics. And the general requirement to use HTTPS is stated elsewhere. I'll update that accordingly as part of IETF last call

Re: [OAUTH-WG] Informal RFC: DPoP using ECDH + HMAC instead of DSA

Hi Zack, For whatever it's worth, HMAC PoP has been discussed in the past (in a few different incarnations). Neil Madden put forth the idea of a somewhat similar sounding Diffie-Hellman style approach https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s/, which I sort of

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-dpop-12.txt

is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) Authors : Daniel Fett Brian Campbell John Bradley

Re: [OAUTH-WG] DPoP - token hash - ASCII encoding question

No bit flipping is needed. It is just meant to say that the bytes of the ASCII representation of the access token value are the input to the hash function. The access token value itself should only be made up of printable ASCII characters https://www.rfc-editor.org/rfc/rfc6749#appendix-A.12 BTW.

Re: [OAUTH-WG] Paul Wouters' Yes on draft-ietf-oauth-rar-19: (with COMMENT)

Apologies Paul, The document editors apparently lost track of the comments with your ballot position leading up to the telechat. I just recently noticed the action to "Please provide clarifying language around the geolocation example and Section 6.1" in the datatracker history

Re: [OAUTH-WG] DPoP examples missing client_id

Thanks for catching that Aaron. I'll fix those two examples accordingly. On Thu, Dec 22, 2022 at 2:39 PM Aaron Parecki wrote: > In section 5, the example access token requests are missing either the > client_id parameter in the POST body or the client authentication in the > HTTP header. > >

Re: [OAUTH-WG] Privacy considerations regarding RAR and authorization_details in AT JWT

I'll just add that RAR is in the very latter stages of IESG processing for publication, which is a point in the process that is not particularly amenable to changes from the WG. On Wed, Dec 21, 2022 at 7:30 AM Justin Richer wrote: > Hi Kai, > > Both of those approaches are common approaches for

Re: [OAUTH-WG] DPoP-Nonce IANA HTTP Header

Thanks Justin, It'll be fixed in the next draft revision. I happened to notice the oversight as well when working on the AD review and have already added it in the document source in github. On Tue, Dec 20, 2022 at 3:44 PM Justin Richer wrote: > DPoP Authors: > > I just noticed that the

Re: [OAUTH-WG] Implementations - OAuth 2.0 Step-up Authentication Challenge Protocol

wrote: > Thanks Brian! > > Any links to public documents that cover this that you could share? > > Thanks, > Rifaat > > > On Tue, Dec 20, 2022 at 8:39 AM Brian Campbell > wrote: > >> Ping Identity has implementations of the functionality in this document >&

Re: [OAUTH-WG] Implementations - OAuth 2.0 Step-up Authentication Challenge Protocol

Ping Identity has implementations of the functionality in this document for the authorization server and resource server roles. On Tue, Dec 20, 2022 at 6:16 AM Rifaat Shekh-Yusef wrote: > All, > > As part of the shepherd write-up for the OAuth 2.0 Step-up Authentication > Challenge Protocol

Re: [OAUTH-WG] IPR Disclosure - OAuth 2.0 Step-up Authentication Challenge Protocol

I am not aware of any IPR associated with this document. On Tue, Dec 20, 2022 at 6:11 AM Rifaat Shekh-Yusef wrote: > Authors, > > As part of the shepherd write-up, all authors of OAuth 2.0 Step-up > Authentication Challenge Protocol > must confirm that any and all appropriate IPR disclosures

Re: [OAUTH-WG] Step-up Authentication Shepherd Review

On Mon, Dec 19, 2022 at 3:38 PM Rifaat Shekh-Yusef wrote: > > > On Mon, Dec 19, 2022 at 4:40 PM Brian Campbell > wrote: > >> Hi Rifaat, >> >> I certainly didn't expect a response over the weekend. Apologies if the >> timing of my message (late aftern

Re: [OAUTH-WG] Step-up Authentication Shepherd Review

: > > On Fri, Dec 16, 2022 at 5:50 PM Brian Campbell > wrote: > >> >> On Tue, Dec 13, 2022 at 2:58 PM Rifaat Shekh-Yusef < >> rifaat.s.i...@gmail.com> wrote: >> >> >> >>> * Section 5 >>> >>> “when it comes to acces

Re: [OAUTH-WG] Step-up Authentication Shepherd Review

Thanks for the review and shepherding Rifaat, Please see inline below where I've endeavored to reply to your comments. A -07 draft with the respective changes is forthcoming. On Tue, Dec 13, 2022 at 2:58 PM Rifaat Shekh-Yusef wrote: > Vittorio, Brian, > > The following is my document shepherd

Re: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-rar-18: (with COMMENT)

-19 has those changes. On Mon, Dec 12, 2022 at 10:23 AM Brian Campbell wrote: > Thank you for the review and ballot Lars. I believe we can easily > incorporate those suggestions. > > > > > On Mon, Dec 12, 2022 at 7:14 AM Lars Eggert via Datatracker < > nore...@ietf.o

Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-rar-18: (with COMMENT)

Thanks Francesca, I must admit that I was not aware of RFC9237. After a quick look, however, it really is intended for Ace and IoT (as you point out) and I don't believe I could write anything sufficiently meaningful about any similarities to this document to warrant inclusion. On Mon, Dec 12,

Re: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-rar-18: (with COMMENT)

Thank you for the review and ballot Lars. I believe we can easily incorporate those suggestions. On Mon, Dec 12, 2022 at 7:14 AM Lars Eggert via Datatracker < nore...@ietf.org> wrote: > Lars Eggert has entered the following ballot position for > draft-ietf-oauth-rar-18: No Objection > > When

Re: [OAUTH-WG] [IANA #1261154] expert review for draft-ietf-oauth-rar (OAuth Parameters - OAuth Extensions Error)

Thanks for catching that Hannes. I believe you are correct that a copy-and-paste error went unnoticed. I have fixed the glitch with a draft -18 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-18 On Thu, Dec 8, 2022 at 4:16 AM Hannes Tschofenig wrote: > Hi all, > > Thanks for the

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-selective-disclosure-jwt-02.txt

Yasuda Brian Campbell Filename: draft-ietf-oauth-selective-disclosure-jwt-02.txt Pages : 59 Date: 2022-12-07 Abstract: This document specifies conventions for creating JSON Web Token (JWT) documents that support selective disclosure

Re: [OAUTH-WG] draft-ietf-oauth-selective-disclosure-jwt

Thanks for the further remarks, Hannes. I'll work with the authors on appropriately adding some additional background/context. On Mon, Dec 5, 2022 at 3:39 AM Hannes Tschofenig wrote: > Thanks for the response, Brian. > > > > A few remarks below. > > > > *From:* Brian

Re: [OAUTH-WG] [Gen-art] [Last-Call] Genart last call review of draft-ietf-oauth-rar-15

and “http://example.com/“ would all be different > “type” values according to RAR because the strings are different. > > — Justin > > On Dec 1, 2022, at 3:45 PM, Brian Campbell < > bcampbell=40pingidentity@dmarc.ietf.org> wrote: > > > > On Wed, Nov 30, 2022 at

Re: [OAUTH-WG] [Gen-art] [Last-Call] Genart last call review of draft-ietf-oauth-rar-15

On Wed, Nov 30, 2022 at 5:04 PM Robert Sparks wrote: > > On 11/30/22 5:53 PM, Brian Campbell wrote: > > > > On Wed, Nov 30, 2022 at 4:08 PM Robert Sparks > wrote: > >> >> On 11/30/22 2:39 PM, Brian Campbell wrote: >> >> >> >

Re: [OAUTH-WG] [Gen-art] [Last-Call] Genart last call review of draft-ietf-oauth-rar-15

On Wed, Nov 30, 2022 at 4:08 PM Robert Sparks wrote: > > On 11/30/22 2:39 PM, Brian Campbell wrote: > > Thank you for the review Robert. And apologies for the very delayed > response. I think we had a bit of a volunteer's dilemma > <https://en.wikipedia.org/wiki/Volunteer

Re: [OAUTH-WG] [Gen-art] [Last-Call] Genart last call review of draft-ietf-oauth-rar-15

Thank you for the review Robert. And apologies for the very delayed response. I think we had a bit of a volunteer's dilemma amongst the editors, which was exacerbated by some timing issues including vacation and subpar communication amongst us.

Re: [OAUTH-WG] draft-ietf-oauth-selective-disclosure-jwt

Hi Hannes, Though I am yet to officially have my name on the document as a co-author, you did mention me directly :) And so I'll attempt to answer or respond to your questions/statements below. On Mon, Nov 28, 2022 at 7:24 AM Hannes Tschofenig wrote: > Hi Daniel, Hi Kristina, Hi Brian, > > Hi

Re: [OAUTH-WG] DPoP questions (post IETF 115), part 1

> On Wed, Nov 16, 2022 at 1:49 PM Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >> >> >> On Mon, Nov 14, 2022 at 5:18 PM Dmitry Telegin > 40backbase@dmarc.ietf.org> wrote: >> >>> >>> To sum up, my idea is that in cases when we

Re: [OAUTH-WG] DPoP questions (post IETF 115), part 1

On Mon, Nov 14, 2022 at 5:18 PM Dmitry Telegin wrote: > > To sum up, my idea is that in cases when we can unambiguously establish > the scheme used, we should include error info into the corresponding > challenge only. In cases of ambiguity, both challenges should be used to > deliver error

Re: [OAUTH-WG] DPoP questions (post IETF 115), part 2

Hello Dmitry, TLDR: yes DPoP and Step-Up can be used together. The first sentence in the section of step-up that describes the new bits for the WWW-Authenticate even explicitly mentions DPoP: https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-06.html#section-3 and other

Re: [OAUTH-WG] Artart last call review of draft-ietf-oauth-rar-14

Thanks Thomas, We will certainly incorporate those fixes/suggestions. On Fri, Nov 4, 2022 at 4:00 PM Thomas Fossati via Datatracker < nore...@ietf.org> wrote: > Reviewer: Thomas Fossati > Review result: Ready > > This document defines an OAuth parameter ("authorization_details") to > carry

Re: [OAUTH-WG] RAR WGLC feedback

Thanks Aaron, The timing here is a bit awkward as the draft is actually in IETF wide last call. But the AD has requested publication of a new -15 draft soon and concurrent with the LC to address some residual feedback from his review that didn't make it into -14. I'd like to aim to get changes

Re: [OAUTH-WG] AD Review of draft-ietf-oauth-dpop-11

Thank you for the detailed review, Roman. I've endeavored to reply to each item inline below. On Thu, Oct 27, 2022 at 7:50 PM Roman Danyliw wrote: > Hi! > > I performed an AD review on draft-ietf-oauth-dpop-11. Thanks for this > document. Comments below. > > ** The document has 6 listed

Re: [OAUTH-WG] Draft Proposal for a Cross Device Flow Security BCP

And I just happened to notice there are a few mentions of RFC8682 (TinyMT32 Pseudorandom Number Generator) which should probably be RFC8628 (OAuth 2.0 Device Authorization Grant). On Fri, Oct 21, 2022 at 4:06 PM Brian Campbell wrote: > Just want to try and clarify some things about the sta

Re: [OAUTH-WG] Draft Proposal for a Cross Device Flow Security BCP

Just want to try and clarify some things about the status of CIBA, which is described somewhat erroneously as a "standard under development." There is a FAPI profile of CIBA that is still under development but core CIBA

Re: [OAUTH-WG] WGLC for Step-up Authentication

ky and have forward compatibility in many implementations >>> as products often implement both OAuth and OIDC in the same codebase, but >>> once again - that is definitely not required. >>> >>> 4- Also in this case, I am not sure how to read this objection. The use >>> of the *t

Re: [OAUTH-WG] WGLC for Step-up Authentication

f the *term* "freshness" has precedent in IETF specs (see rfc8747) and is >> commonly used in discussions on the list; and the concept is very well >> known and understood, as the existence of the max_age parameter attests; >> the fact that it is defined in OIDC doesn't rea

Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12

On Fri, Oct 14, 2022 at 10:50 AM Roman Danyliw wrote: > > > > > > > ** Section 11.2 > > > > > > One option would be to have a mechanism allowing the registration of > > > extension modules, each of them responsible for rendering the > > > respective user consent and any transformation

Re: [OAUTH-WG] WGLC for Step-up Authentication

an avoid forcing the > complete authentication cycle at client end. > > Regards > Jaimandeep Singh > > > On Wed, Oct 12, 2022 at 3:25 AM Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >> I don't know offhand a better place or if your specific privacy >&

Re: [OAUTH-WG] WGLC for Step-up Authentication

I don't know offhand a better place or if your specific privacy consideration is already covered. Honestly, with that comment, I was just aiming to keep the scope of this document concise and relevant. On Tue, Oct 11, 2022 at 10:06 AM Denis wrote: > Hi Brian, > > I agree with you that "must

Re: [OAUTH-WG] WGLC for Step-up Authentication

Thanks Denis, I agree the word "cannot" isn't quite right there. I struggled with trying to find the right wording (more than I probably should have) attempting to add a note/reminder without getting into normative sounding language. But I also wanted to make a firm statement. Words are hard

Re: [OAUTH-WG] WGLC for Step-up Authentication

I forgot to add Dima to the acknowledgements yesterday when doing -04 (thanks Vittorio for catching that). I'll rectify that shortly. On Mon, Oct 10, 2022, 4:53 PM Brian Campbell wrote: > I've published an -04. It has that very minor change. There was also an > off-list discussion durin

Re: [OAUTH-WG] WGLC for Step-up Authentication

I've published an -04. It has that very minor change. There was also an off-list discussion during WGLC that resulted in thinking it'd be worthwhile to add a reminder that access tokens are opaque to clients. So I took that as LC feedback and -04 adds a brief note towards that end.

Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12

Thanks for the review Roman and thanks Justin for the responses. I took the liberty of going ahead and making some of the more straightforward changes suggested by the review in the document source https://github.com/oauthstuff/draft-oauth-rar/commit/575f21bf6369c609f673062ec2083215c797b4c2 so as

Re: [OAUTH-WG] Guidelines in what I need to do on here

If we're being honest, I often have those very same questions... On Tue, Aug 23, 2022 at 6:51 AM Susan Griffis wrote: > Please explain to me what this is all about And how I got myself in this > and what it works for. Thanks > > Sent from my iPhone >

Re: [OAUTH-WG] Certificate-bound refresh tokens and certificate expiration handling in case of the confidential clients

Hi Mikheil, Your assumption is the correct reading of the RFC. Or the intent of the RFC anyway. For confidential clients, refresh tokens are bound to the client id (not the certificate thumbprint or anything else for that matter). RFCs can't be changed after publication so adding more

Re: [OAUTH-WG] DPoP - IPR Disclosure

I am not aware of any IPRs associated with this document. On Wed, Aug 10, 2022 at 3:38 PM Rifaat Shekh-Yusef wrote: > Daniel, Brian, John, Torsten, Mike, and David, > > As part of the shepherd write-up for the *DPoP* document, there is a need > for an IPR disclosure from the authors. >

Re: [OAUTH-WG] DPoP - Document Shepherd Review

> tokens instead of a separate security consideration because it’s really > fundamental to the token use here. > > — Justin > > > On Jul 27, 2022, at 7:11 PM, Brian Campbell < > bcampbell=40pingidentity@dmarc.ietf.org> wrote: > > I need to make one more apo

  1   2   3   4   5   6   7   8   9   10   >