[jose] Re: HPKE and diminishing returns

To be clear, empty components are not the concern (or my concern anyway). The inappropriate, nonconforming, problematic, etc. use of existing RFC defined constructs is my concern. I believe Neil's concern is more meta and questioning whether this line of work should even be pursued. Which I

[jose] Re: [EXTERNAL] Re: HPKE and diminishing returns

API seems like a whole lot of complex breaking changes in the > name of simplicity. I would cherry-pick the useful ideas out of 9180 and > add the minimum amount of new message types to support KEMs. > > > > I have not been following this thread in detail, so I hope this was > helpfu

[jose] Re: HPKE and diminishing returns

/doc/html/rfc9180#section-9.4 > Protected Headers - alg, enc, ek, psk_id > > 2 Layer (Indirect / JSON Serialization, etc...) > HPKE-Base-P256-SHA256-A128GCM upgrades { alg: ECDH-ES+A128KW } ... { enc: > A128GCM } > 1 Layer (A new kind of "direct encryption"... "do

[jose] Re: Call for Adoption for draft-rha-jose-hpke-encrypt

I do not support adoption, and point to threads starting here https://mailarchive.ietf.org/arch/msg/jose/-9qqpbmn4kzN-LIBtzift-s7BzY/ and here https://mailarchive.ietf.org/arch/msg/jose/f6O0c4OoVTeRKUfves6tyOXuAN0/ as some reasoning thereof. I realize this is late and apologize for that. It can

[jose] Re: HPKE and diminishing returns

On Thu, Jun 13, 2024 at 1:47 AM Neil Madden wrote: > Hi all, > > We appear to have yet another long WG discussion going on about how to try > to squeeze the ground meat of HPKE into the intestinal lining of JOSE. I > know that I at least don’t have the time to follow the minutiae of these >

[jose] Re: epk -> ek: Aligning JOSE HPKE to COSE HPKE

On Tue, Jun 11, 2024 at 1:43 AM Neil Madden wrote: > > > On 10 Jun 2024, at 22:30, Orie Steele wrote: > >  > Brian wrote: > > > The 'dir" Key Management algorithm for JWE is defined in JWA as Direct > Encryption with a Shared Symmetric Key, which is not what's happening with > that HPKE Direct

[OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-selective-disclosure-jwt-09.txt

Greetings fellow OAUTH WG mail list subscribers, It is with great pleasure that I announce the recent publication of the -09 draft of the SD-JWT document. The usual datatracker, etc. links are below along with a quick summary of the changes in this revision (copied from the document history). I

[jose] Re: epk -> ek: Aligning JOSE HPKE to COSE HPKE

On Sun, Jun 9, 2024 at 11:06 PM tirumal reddy wrote: > On Sat, 8 Jun 2024 at 02:39, Orie Steele > wrote: > >> >> >> On Fri, Jun 7, 2024, 3:09 PM Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote: >> >>> Couching my comments inline below

[jose] Re: epk -> ek: Aligning JOSE HPKE to COSE HPKE

On Fri, Jun 7, 2024 at 3:08 PM Orie Steele wrote: > > > On Fri, Jun 7, 2024, 3:09 PM Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >> Couching my comments inline below with my own experience or lack thereof: >> I've got a 10+ year old JOSE/JWT imple

[jose] Re: epk -> ek: Aligning JOSE HPKE to COSE HPKE

Couching my comments inline below with my own experience or lack thereof: I've got a 10+ year old JOSE/JWT implementation that supports JWE compact serialization and is still in (relatively) widespread use, so I have some knowledge in that area. However, I'm only a casual observer of HPKE and the

[OAUTH-WG] Re: [Technical Errata Reported] RFC9470 (7951)

I suspect a variety of not-entirely-improbable rational could be provided to explain why it might make sense. But the reality is that it's just a mistake in the document where somewhere along the way updates were made to the examples that didn't fully align with content already in those examples.

[jose] Re: "Ed25519 not recommended" Re: WGLC for draft-ietf-jose-fully-specified-algorithms

I assume this question is referring to the "COSE Recommended" column in the table in Sec 2.2 ? Which incidentally is inconsistent with the values in the COSE algorithm registration

Re: Topband: Dayton 2024

of us. 73, Brian MGY From: Topband on behalf of Brian Campbell Sent: May 20, 2024 8:02 AM To: topband@contesting.com Subject: Topband: Dayton 2024 Good Morning fellow Topbanders, To say that it was absolutely fantastic to meet my fellow Topband Friends

Topband: Dayton 2024

Good Morning fellow Topbanders, To say that it was absolutely fantastic to meet my fellow Topband Friends ( and Legends!! ) of the Topband fraternity would be the understatement of the year!! I thoroughly enjoyed each and every conversation, handshake, and "eyeball" QSO with each of you. I

[jose] Re: "Ed25519 not recommended" Re: WGLC for draft-ietf-jose-fully-specified-algorithms

On Fri, May 10, 2024 at 3:28 AM Ilari Liusvaara wrote: > On Wed, May 08, 2024 at 10:53:48AM -0600, Brian Campbell wrote: > > > > Messages in this thread seem to be getting lost somewhere and I don't > think > > it's just me as they don't seem to show up in

[jose] Re: WGLC for draft-ietf-jose-fully-specified-algorithms

On Mon, May 6, 2024 at 11:11 AM Michael Jones wrote: > The draft is solving a real problem that’s not hypothetical. Multiple > specifications by multiple working groups across both JOSE and COSE have > had to create workarounds for the problems that polymorphic algorithm > identifiers are

[jose] Re: "Ed25519 not recommended" Re: WGLC for draft-ietf-jose-fully-specified-algorithms

Messages in this thread seem to be getting lost somewhere and I don't think it's just me as they don't seem to show up in the archives either. But I tried to send something yesterday with the observation that the "no" in question here in the "COSE

[OAUTH-WG] Re: WGLC for Browser-Based Apps

I just glanced through the draft looking for my name (everyone does that, right?) and noticed my surname misspelled in a couple of the references (Cambpell should be Campbell). Might I kindly ask the document editors, one of whom has been my co-worker for 20+ years, to correct this? And probably

Re: [OAUTH-WG] OAuth Digest, Vol 187, Issue 6

Итак, у нас есть еще девять дней этих сообщений? On Sun, May 5, 2024 at 1:02 PM Konstantin Korsakov wrote: > Я в отпуске до 13 мая. По срочным вопросам - звоните или пишите в Телеграм. > ___ > OAuth mailing list > OAuth@ietf.org >

Re: [jose] Fully-specified ECDH algorithms

I am not supportive of addressing this in draft-ietf-jose-fully-specified-algorithms with the definition of a bunch of new algorithms. That message I sent previously[1] was little more than an offhand musing and shouldn't be construed as an actual suggestion. [1]

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: [jose] Deprecation of legacy algorithms

The JWE RSA1_5 alg is not required for OpenID Connect as far as I know? On Tue, Mar 5, 2024 at 9:39 AM Michael Jones wrote: > I would not support deprecation of either of these algorithms. They are > both required for OpenID Connect and are in extremely widespread use. > > > > *From:* jose

Re: [jose] I-D Action: draft-ietf-jose-fully-specified-algorithms-01.txt

For JOSE encryption, I think the 4 deprecated algorithms would be ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192K, and ECDH-ES+A256KW. But it seems like there could be as many as 20 new algorithms - one of each of the above combined with each of EC/P-256, EC/P-384, EC/P-521, OKP/X25519, and OKP/X448.

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: [jose] I-D Action: draft-ietf-jose-fully-specified-algorithms-00.txt

Thanks! It is and will be nice to have that history there. On Wed, Jan 31, 2024 at 9:53 AM Orie Steele wrote: > done. > > On Wed, Jan 31, 2024 at 10:46 AM Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >> Logistics nit - would it be possible for the chai

Re: [jose] I-D Action: draft-ietf-jose-fully-specified-algorithms-00.txt

Logistics nit - would it be possible for the chairs or authors to mark this one as replacing draft-jones-jose-fully-specified-algorithms? The linkage doesn't currently show up in datatracker. https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/

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,

[INDOLOGY] The Cidvilāsastava of Amṛtānanda: New Translation Announcement

ilasastava Best wishes, Brian Campbell ___ INDOLOGY mailing list INDOLOGY@list.indology.info https://list.indology.info/mailman/listinfo/indology

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: [jose] JWP focus/scope

On Fri, Nov 10, 2023 at 1:53 PM Orie Steele wrote: > Inline > > On Fri, Nov 10, 2023, 9:27 PM Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >> I was rewarded for a comment in the meeting today* with an action item to >> start a discussion on-list. S

[jose] JWP focus/scope

I was rewarded for a comment in the meeting today* with an action item to start a discussion on-list. So here I am with that. It's difficult (for me anyway) to articulate some of this in writing, which is why I wanted to voice it in the meeting. But that got redirected back to the list so here's

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: [jose] draft-tschofenig-jose-cose-guidance-00

On Mon, Oct 30, 2023 at 8:20 AM Ilari Liusvaara wrote: > On Mon, Oct 30, 2023 at 07:55:09AM -0600, Brian Campbell wrote: > > On Tue, Oct 24, 2023 at 4:46 AM Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > And another is why Dire

Re: [jose] draft-tschofenig-jose-cose-guidance-00

On Tue, Oct 24, 2023 at 4:46 AM Ilari Liusvaara wrote: > On Tue, Oct 24, 2023 at 07:19:59AM +0200, hannes.tschofe...@gmx.net wrote: > > Hi all, > > > > Les and I have put together a draft that starts to capture guidance > > for JOSE (and COSE) following the recent list discussion about key > >

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

Re: [jose] Fully-Specified Algorithms for JOSE and COSE

On Wed, Aug 30, 2023 at 2:22 AM Filip Skokan wrote: > Hello Mike, everyone, > > After a quick read I have just one note, already mentioned on the list, > the JOSE ES prefix for Ed* feels wrong and I would suggest to use the sub > type values as alg values, that is Ed25519 and Ed448 instead of

[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: [regext] [IANA #1279353] expert review for draft-ietf-regext-rdap-openid (jwt)

I've reviewed just the JWT claims registration requests and don't have any objection to the registration of "rdap_allowed_purposes" and "rdap_dnt_allowed" being made. I am not in a position to review the entire document so my reply here is limited in scope to only the claims registration. On

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: [Gen-art] 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] 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: [Gen-art] 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: [Gen-art] Genart last call review of draft-ietf-httpbis-client-cert-field-04

://httpwg.github.io/http-extensions/draft-ietf-httpbis-client-cert-field.txt=https://httpwg.github.io/http-extensions/cert/genart-review/draft-ietf-httpbis-client-cert-field.txt On Fri, Feb 24, 2023 at 3:16 PM Brian Campbell wrote: > Thank you Peter for the thorough review! > > I'll m

Re: [Gen-art] Genart last call review of draft-ietf-httpbis-client-cert-field-04

Thank you Peter for the thorough review! I'll make those clarifications re: Client-Cert and Client-Cert-Chain in sec 2 and the appx. Although I think adding the root certificate to Client-Cert-Chain is more of a 'can' than a 'should' depending on deployment needs. Regardless, I'll add some text

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: Topband: CQWW160: Night 2

Correction on the opening time typo ( still tired ). It was from 0251z to 0623z ( not 0215z ). From: Topband on behalf of Brian Campbell Sent: January 30, 2023 9:24 AM To: Don Kirk ; Michael Tope Cc: topband@contesting.com Subject: Re: Topband: CQWW160: Night

Re: Topband: CQWW160: Night 2

This enhancement also happened in SW Ontario. I was also LP ( unassisted ) so as I S'd I would enter each call into the bandmap ( dupe or not ) to keep track of what trace was who so I could pop back between runs to try and grab the unworked ones. At about 0215z all the EU traces I was watching

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 >&

  1   2   3   4   5   6   7   8   9   10   >