[OAUTH-WG] Re: [Technical Errata Reported] RFC7591 (7969)

This errata seems to be correct, an omission in the example that doesn't align with the normative requirements. From: RFC Errata System Sent: Monday, June 3, 2024 1:30 PM To: i...@justin.richer.org ; m...@microsoft.com ; ve7...@ve7jtb.com ;

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

This seems to be logical - the authentication event would always be before the token was issued in the usual case. However, assuming that the AS "upgrades" an existing token in-place during a step up, isn't it possible for the latest relevant authentication event to come after the token was

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

AM To: Justin Richer Cc: oauth Subject: Re: [OAUTH-WG] OAuth for Browser-Based Apps Hi Justin, Thank you for your detailed review. > §9+ this draft should add privacy considerations, particularly for BFF > pattern's proxy architecture.e I wanted to ask for a bit more context on this c

Re: [OAUTH-WG] draft-zhang-jose-json-fine-grained-access

Thank you for presenting your proposal to the group in Brisbane. Reading through the draft, it seemed that there are really two topics in here, and I'm wondering how they could be split: 1, a data structure for complex access rights 2, a cryptographic mechanism for selectively encrypting some

Re: [OAUTH-WG] DPoP introspection not including verification

While I don’t have an answer for the question asked, I do want to note that in order to do a proper validation, the introspection request would have to include the values of the DPoP proof, but also the expected HTM and HTU values from the RS, as the AS would not know these directly. — Justin

[OAUTH-WG] OAuth for Browser-Based Apps

As promised at the last meeting, I have been able to do a full review of the OAuth for Browser Based Applications draft spec, and my notes are attached, indexed by sections and paragraphs where possible. Even though my notes are extensive, I do want to say that overall the document is in great

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

_ From: Brian Campbell mailto:40pingidentity@dmarc.ietf.org>> Sent: Friday, February 23, 2024 11:25:56 AM To: Justin Richer Cc: Cecchetti, Sarah; oauth Subject: RE: [EXTERNAL] [OAUTH-WG] For review/discussion: Cedar profile of OAuth Rich Authorization Re

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

Hi Sarah, Thanks for putting that draft together. As one of the authors of RAR, I wanted to chime in. First, I do think that this is a great use of RAR. The whole idea behind RAR was to give people structures that they could use beyond what scopes allow, and tying this to a computable policy

Re: [OAUTH-WG] [Technical Errata Reported] RFC7591 (7782)

I believe this correction is valid, though I think that the changing of a normative requirement is beyond an erratum. Ultimately, though, this comes down to the definition of what "a client" is, which is pretty fuzzy in OAuth. The AS needs to be able to issue the same identifier to what it

Re: [OAUTH-WG] [Errata Rejected] RFC7519 (5648)

As much as I agree that suggesting a pronunciation in a spec like this is silly, I believe the errata should be rejected as the text was agreed upon by the WG as it stands. This is not an error, but rather a stylistic disagreement from the reporter. -Justin

Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23

On Jan 3, 2024, at 12:30 PM, axel.nenn...@telekom.de wrote: The email discussion triggered me jumping into the discussion. Also, I am looking into this from a Camara PoV. https://github.com/camaraproject/IdentityAndConsentManagement Camara is about to define what is a MUST for authorization

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

This errata should be rejected, as stated in the write up, the change in text is too much for an errata. If the WG wants to revise JWT at this level it should be a full bis document. It's worth noting that the two other time based claims, nbf and exp, allow for clock skew in processing, but

Re: [OAUTH-WG] sub_id in draft for Transaction tokens

I disagree with the utility of just "sub" here. The subject of the token is always contextual to the issuer of that subject - however, the "iss" field here is the issuer of the transaction token and not the issuer of the subject identifier. As such, it's much less ambiguous to use the compound

Re: [OAUTH-WG] Reservations and observations about draft JWT and CWT Status List

Your premise relies on a feature of JSON that does not exist. JSON does not provide well-defined behavior for repeated names within an object: When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. From:

Re: [OAUTH-WG] Review of draft-ietf-regext-rdap-openid

Hi Roman, The concerns of this document are largely specific to OpenID Connect, and not vanilla OAuth, but of course many of us in the community overlap and I’m happy to help provide some feedback here. I’m not familiar with RDAP, so if any of my concerns are addressed by other aspects of the

Re: [OAUTH-WG] Questions on OAuth Protected Resource Metadata

I think we’re used to thinking of scopes in terms of things that a developer can read and understand, but that’s not always going to be true. For automated systems like this, the developer isn’t always expected to understand the scope — they probably don’t even see it in many cases. The client

[OAUTH-WG] Fwd: New Version Notification for draft-gilman-wimse-use-cases-00.txt

g list. Thanks, — Justin Begin forwarded message: From: internet-dra...@ietf.org Subject: New Version Notification for draft-gilman-wimse-use-cases-00.txt Date: August 28, 2023 at 1:53:01 PM EDT To: "Evan Gilman" , "Joseph Salowey" , "Justin Richer" , "Piete

Re: [OAUTH-WG] [Technical Errata Reported] RFC7662 (7607)

ftware Park Road, Dalian, Liaoning, China From: Justin Richer Sent: 2023年8月18日 20:54 To: RFC Errata System ; i...@justin.richer.org; r...@cert.org; paul.wout...@aiven.io; hannes.tschofe...@arm.com; rifaat.s.i...@gmail.com Cc: sunful...@neusoft.edu.cn; oauth@ietf.org Subject: Re: [OAUTH-WG] [Tec

Re: [OAUTH-WG] [Technical Errata Reported] RFC7662 (7607)

The resource owner can revoke the token out of band, this errata should be rejected. - Justin From: OAuth on behalf of RFC Errata System Sent: Thursday, August 17, 2023 2:42 PM To: i...@justin.richer.org ; r...@cert.org ; paul.wout...@aiven.io ;

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

This errata seems to be spam. From: OAuth on behalf of RFC Errata System Sent: Friday, July 21, 2023 10:32 PM To: rfc-edi...@rfc-editor.org Cc: brunoatlass...@outlook.com.br ; oauth@ietf.org Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7569) The

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

Hi al — sorry, I missed these first couple emails entirely. Yes, I have read the document and I approve this registration. — Justin > On Apr 12, 2023, at 1:45 AM, Amanda Baber via RT > wrote: > > Hi Justin, > > Can you review this OAuth Dynamic Client Registration Metadata request before

Re: [OAUTH-WG] [IANA #1267319] expert review for draft-ietf-oauth-step-up-authn-challenge (oauth-parameters)

These two registrations look good to me. Thanks, — Justin > On Feb 27, 2023, at 6:11 PM, David Dong via RT > wrote: > > Dear Justin (cc: oauth wg), > > As the designated expert for the OAuth Token Introspection Response registry, > can you review the proposed registration in >

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

Hi Mark, a quick note on one item: - Section 4.1 defines the DPoP header field as a JWT, which (as I understand it) is a base64-encoded string. If that's the case, I'd recommend making it a Structured Field Item (see RFC8941 s 3.3) with a fixed type of Byte Sequence (s 3.3.5). That will

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

I agree with Brian’s proposed fix — that is a “target URI” as defined by “HTTP”. The fact that it’s :also: required to be HTTPS is separate. — Justin On Jan 9, 2023, at 7:58 AM, Brian Campbell mailto:bcampbell=40pingidentity@dmarc.ietf.org>> wrote: Thanks Dominick, I believe they

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

Hi Kai, Both of those approaches are common approaches for preventing the leakage of private information in JWTs, and neither is specific to the RAR specification. The use of RAR objects does make it easier to have more specific detail, but that detail could have easily been leaked through a

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

source in github. On Tue, Dec 20, 2022 at 3:44 PM Justin Richer mailto:jric...@mit.edu>> wrote: DPoP Authors: I just noticed that the DPoP-Nonce header is not registered in the current version of the DPoP spec. This should be added under section 12.8, HTTP Message Header Field Names

[OAUTH-WG] DPoP-Nonce IANA HTTP Header

DPoP Authors: I just noticed that the DPoP-Nonce header is not registered in the current version of the DPoP spec. This should be added under section 12.8, HTTP Message Header Field Names Registration. It’s a clerical oversight but needs to be fixed before the document is finalized. — Justin

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

Apologies, sending from the correct email account this time. Please do not reply to the other address. Thank you, — Justin On Dec 12, 2022, at 1:45 PM, Justin Richer mailto:jus...@richer.org>> wrote: Francesca, Thanks for the pointer! I read through the referenced RFC as well and I

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

FWIW, this is in line with what I understood the previous sentences to mean as well — so I’m happy for this being a simpler and more precise language. What we were really trying to avoid is things like, for example, someone putting a URI in as their “type” value and doing URI-level equivalence

Re: [OAUTH-WG] Call for adoption: Cross-Device Flows

I support adoption of this draft. It’s important work that affects a number of areas in and around OAuth. — Justin On Nov 15, 2022, at 6:43 AM, Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com>> wrote: All, During the IETF meeting last week, there was a strong support for the adoption of

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

en > addressed there. Combing through the multiple sub-threads, I've pruned to > text to cover what is the residual feedback. See below. > > To keep this document moving, I'm going to start IETF LC on it. Please > address this feedback concurrently. > >>> -----Original Mess

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

Thank you, Torsten! — Justin On Oct 24, 2022, at 12:18 PM, Torsten Lodderstedt mailto:tors...@lodderstedt.net>> wrote: Hi Roman, I just published revision -14 with the all the agreed changes. https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html best regards, Torsten. Am 24.10.2022

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

On Oct 14, 2022, at 12:50 PM, Roman Danyliw mailto:r...@cert.org>> wrote: Hi Justin! -Original Message----- From: Justin Richer mailto:jric...@mit.edu>> Sent: Thursday, September 15, 2022 11:20 AM To: Roman Danyliw mailto:r...@cert.org>> Cc: oauth@ietf.org<mailto:oauth@i

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

Hi Roman, some responses inline. > On Sep 14, 2022, at 6:30 PM, Roman Danyliw wrote: > > Hi! > > I performed an AD review of draft-ietf-oauth-rar-12. Thanks for this > document. My feedback is as follows: > > ** Section 2. Editorial > > This field MUST be compared using an exact byte

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

signature for and have it work. — Justin On Aug 5, 2022, at 1:00 PM, Justin Richer mailto:jric...@mit.edu>> wrote: I think Brian’s just in Danial about this one, but we’ll let it slide. And I have in fact gone through and added text about ATH: https://github.com/danielfett/draft-d

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

I think Brian’s just in Danial about this one, but we’ll let it slide. And I have in fact gone through and added text about ATH: https://github.com/danielfett/draft-dpop/pull/168 I opted to add this in the introduction of the section about using access tokens instead of a separate security

Re: [OAUTH-WG] Protected resource access error codes (draft-ietf-oauth-v2-1-05, §5.2.3)

The response from the RS is not the purview of the core OAuth framework RFC6749 but the token presentation, RFC6750, which has this to say on the matter: When a request fails, the resource server responds using the appropriate HTTP status code (typically, 400, 401, 403, or 405) and

Re: [OAUTH-WG] IPR Disclosures - OAuth 2.0 Rich Authorization Requests

I am not aware of any IPR issues for this specification and have no disclosures to make. — Justin > On Apr 6, 2022, at 9:34 AM, Hannes Tschofenig > wrote: > > Authors, > > as part of the shepherd write-up, all authors of draft-ietf-oauth-rar must > confirm > that any and all appropriate

Re: [OAUTH-WG] WGLC for DPoP Document

t; Suppose that the token indicates "over 18". If the user is over 18 now, he >>> will certainly be "over 18" the next days, months or years. >>> There is no need to refresh the token as it would be the case if the token >>> inclu

Re: [OAUTH-WG] WGLC for DPoP Document

n clients. > > The illegitimate client can do anything it wants without disclosing what it > is doing to the legitimate client. > The traffic between the clients is kept to the very minimum. > > Denis > >> +1 >> >> Am 29.03.22 um 15:10 schrieb Justin Richer: &

Re: [OAUTH-WG] access token hash claim name in oauth-dpop draft

Yes, it was considered, discussed, and rejected. The reason being “at_hash” has a somewhat convoluted definition (left-bits of a hash of an access token in the context of a JOSE object, etc), to fit some of the design constraints of ID Tokens. DPoP proofs do not have those same constraints.

Re: [OAUTH-WG] WGLC for DPoP Document

And this is exactly the problem with the “collaborating clients” attack, as has been pointed out any number of times it’s been brought up before. If two clients are willingly collaborating in this way, they do not need to share any cryptographic material and impersonate each other. You don’t

Re: [OAUTH-WG] DPoP and Client Registration Access Token

Way back when we wrote dynamic registration, we made the decision to always have the registration token just be a bearer token. Part of this is because OAuth2 doesn’t really have a separate “access token” data structure that we could just replicate in this spot, so there’s no “token type” or

Re: [OAUTH-WG] can a resource server provide indications about expected access tokens?

Hi Nikos, If you mean indicate to the client, then in my view, no — not directly in a delegation protocol like OAuth, at least. The format of the token, and its contents, are abstracted away. As has been mentioned in the thread already, you can return a “scope” and other parameters to the

Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

I disagree with this take. If there are confirmation methods at all, it’s no longer a Bearer token, and pretending that it is doesn’t help anyone. I think combining confirmation methods is interesting, but then you get into a weird space of how to define the combinations, and what to do if one

Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate

ained access token. > > Regards, > Takashi Norimatsu > Hitachi, Ltd. > > From: Justin Richer > Sent: Tuesday, November 16, 2021 1:18 AM > To: Dmitry Telegin > Cc: oauth ; 乗松隆志 / NORIMATSU，TAKASHI > > Subject: [!]Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error cod

Re: [OAUTH-WG] DPoP and MTLS - friends or foes?

I would expect them to be able to co-exist in an implementation, but not both be used on the same token. One of the implementations that I work on supports both DPoP and MTLS on access tokens (as well as bearer tokens), and we use metadata stored in the token objects to switch between these.

Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate

gt; mechanisms (DPoP, MTLS) could co-exist, or should they be mutually exclusive; > this deserves a separate thread though. > > - Dmitry > > On Thu, Nov 11, 2021 at 10:22 AM Justin Richer <mailto:jric...@mit.edu>> wrote: > Only if this working group wanted to take up the work

Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate

From: Dmitry Telegin [dmit...@backbase.com] Sent: Wednesday, November 10, 2021 1:34 PM To: Justin Richer Cc: oauth Subject: Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate Thanks for the reply. That makes sense. Given that MTLS is not a draft but rather

Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate

This is just my interpretation, but this feels more like invalid token, because you’re not presenting all of the material required for the token itself. The DPoP draft has added “invalid_dpop_proof” as an error code, which I think is even better, but the MTLS draft is missing such an element

Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

Dick, you would probably be interested in the Oblivious HTTP effort that has recently been chartered to solve similar encapsulation problems in HTTP. - Justin From: OAuth [oauth-boun...@ietf.org] on behalf of Dick Hardt [dick.ha...@gmail.com] Sent:

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

I wanted to jump back to the top of the thread to point out something that seems to be getting missed: This is not a call for adoption of HTTP Message Signatures. That document already exists in the HTTP WG and will be published as an RFC from that group. If you want to have discussions

Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

> On Oct 14, 2021, at 8:47 AM, Warren Parad > wrote: > > I feel like there are a bunch of pieces of the implementation fundamentally > missing here, so we are back to, as it is right now, the draft isn't > sufficient. Of course the draft isn’t sufficient for publication — that’s what the

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

Hi Mike, One of the major benefits of this proposed draft is that it does not try to solve the problem of HTTP message signing — which is a huge problem unto itself. When I wrote the original draft-ietf-oauth-signed-http-request, I wasn’t able to write it to depend on a general-purpose HTTP

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

oving and unproven draft in the > HTTP WG is not a good use of resources in the OAuth WG at this time. > > > ᐧ > > On Wed, Oct 6, 2021 at 2:20 PM Justin Richer <mailto:jric...@mit.edu>> wrote: > > HTTP Sig looks very promising, but it has not been ado

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

> HTTP Sig looks very promising, but it has not been adopted as a draft Just to be clear, the HTTP Sig draft is an official adopted document of the HTTP Working Group since about a year ago. I would not have suggested we depend on it for a document within this WG otherwise. — Justin > On Oct

Re: [OAUTH-WG] Adding the option to use server-supplied nonces to DPoP

Hi Mike, thanks for this writeup and bringing this attack surface to the attention of the group! I would like to also discuss how this attack and solution could be applied to the proposed HTTP Message Signatures based draft for OAuth 2:

Re: [OAUTH-WG] OAuth Interim Meetings

I would like to present the proposed HTTP signatures draft, and separately I think it would also be beneficial to the OAuth wg to present an update on the progress of GNAP. -Justin From: OAuth [oauth-boun...@ietf.org] on behalf of Rifaat Shekh-Yusef

Re: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05

This is a fair point... The privacy and security considerations talk about this a bit as I recall, but likely need to in more depth and specificity. This is an intentional message channel to the client from the AS, but if the AS is blindly sending all information it might be saying more than it

Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)

I personally don’t agree with this errata. Token Revocation was never meant to act as a protected resource, but rather as a function of the AS. The client is known to the AS and so authentication is expected here. — Justin > On Aug 22, 2021, at 5:14 AM, RFC Errata System > wrote: > > The

Re: [OAUTH-WG] DPoP 03 - introspection - token_type?

n DPoP though? I'm not sure, to be > honest. > > > > On Mon, Aug 16, 2021 at 5:46 AM Justin Richer <mailto:jric...@mit.edu>> wrote: > Yes, it should be. Good catch. > > -Justin > > From: OAuth [oauth-boun...@ietf.org <mail

Re: [OAUTH-WG] DPoP 03 - introspection - token_type?

Yes, it should be. Good catch. -Justin From: OAuth [oauth-boun...@ietf.org] on behalf of Vladimir Dzhuvinov [vladi...@connect2id.com] Sent: Sunday, August 15, 2021 12:02 PM To: oauth@ietf.org Subject: [OAUTH-WG] DPoP 03 - introspection - token_type? The

Re: [OAUTH-WG] Call for adoption - OAuth Proof of Possession Tokens with HTTP Message Signatures

Needless to say, but as the author of both this draft and the draft that it would replace, I am in favor of adoption of this document. There are still a lot of open questions to answer — such as key introduction and management practices — and I think there is a lot of power in the intersection

Re: [OAUTH-WG] DPoP and implicit/hybrid flows

gt; I don't know if people really care about FAL3, unfourtunatly the simple > solution of using token-binding seems quite dead in browsers. > > John B. > > > > > > On Fri, Jul 16, 2021, 12:29 PM Justin Richer <mailto:jric...@mit.edu>> wrot

Re: [OAUTH-WG] DPoP and implicit/hybrid flows

I personally hope we don’t. JAR already gives us signed requests at the authorization endpoint, though the last piece would be binding the token. — Justin > On Jul 15, 2021, at 6:47 PM, Dmitry Telegin > wrote: > > Hi, > > The DPoP spec currently defines how to obtain a DPoP-bound token

Re: [OAUTH-WG] RAR WGLC comment

I agree with this change, but with one caveat (already expressed in the PR) that an AS should be aware that clients can now send scope, resource, and authorization_details parameters together on a single request. It’s not up to RAR to define how all of those fit together, but an AS implementing

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

I personally agree with this report, the new proposed wording is better. OAuth 2.1 editors, please take note! — Justin > On Jun 22, 2021, at 8:01 PM, Benjamin Kaduk wrote: > > This looks correct to me; could the authors/WG please confirm? > > Thanks, > > Ben > > On Thu, Jun 17, 2021 at

[OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-httpsig-00.txt

0.txt > Date: June 21, 2021 at 11:52:14 AM EDT > To: "Justin Richer" > > > A new version of I-D, draft-richer-oauth-httpsig-00.txt > has been successfully submitted by Justin Richer and posted to the > IETF repository. > > Name: draft-richer-oauth-httpsig

Re: [OAUTH-WG] Can a client send the Authorization Request?

e authorization endpoint needing to be accessible by the user agent >> without MTLS or other funny stuff. >> >> PAR also fits in nicely in that case since the PAR endpoint could be >> protected with MTLS since it *is* intended to only be accessible from the >&g

Re: [OAUTH-WG] Can a client send the Authorization Request?

I'm actually wondering if we should add discussion about not putting mtls on the authorisation endpoint into OAuth 2.1. Aaron et al, thoughts? -Justin From: A. Rothman [amich...@amichais.net] Sent: Tuesday, May 25, 2021 7:03 PM To: Justin Richer Cc

Re: [OAUTH-WG] Can a client send the Authorization Request?

potential attack vectors, if that's also the > case - still trying to figure that one out). Is there any flaw in OAUTH2 that > would require such mTLS on this endpoint? Is it worth the risks involved in > deviating from the normal flow? > > Thanks, > > Amichai >

Re: [OAUTH-WG] Can a client send the Authorization Request?

One point, the client doesn’t POST to the authorization endpoint, the resource owner’s browser is supposed to POST to the authorization endpoint — it’s an important distinction. And in the wild, this is really rare to see in use. As written, this is not compliant with OAuth2. I agree that this

Re: [OAUTH-WG] HTTP Message Signing and OAuth PoP

scuss this. > Do you have a date in mind? > > Regards, > Rifaat & Hannes > > > > > > On Thu, Apr 29, 2021 at 11:34 AM Justin Richer <mailto:jric...@mit.edu>> wrote: > Many of you will remember an old draft that I was the editor of that defi

[OAUTH-WG] HTTP Message Signing and OAuth PoP

Many of you will remember an old draft that I was the editor of that defined OAuth proof of possession methods using HTTP Message Signing. When writing that draft I invented my own scheme because there wasn’t an existing HTTP message signature standard that was robust enough for our use cases.

Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-03.txt

As mentioned, my own intention for using a new claim “ath” was to have a fixed hash size, not dependent on the surrounding JWS envelopes that “at_hash” is based on. I’ve implemented both approaches on several platforms now, and I greatly prefer the fixed hash. It’s a new name because it is a

[OAUTH-WG] Access Token Hash for DPoP

As discussed on the call yesterday, I have put together a modest proposal for adding access token hash to the DPoP draft. https://github.com/danielfett/draft-dpop/pull/62 Instead of using the existing OpenID Connect “at_hash” claim and

Re: [OAUTH-WG] One-time token login

I agree that it seems strange to use the authorization code in such a manner, though I can see how it could work on a technical basis. While it’s not an exact match, you might want to look at the Device Grant: https://tools.ietf.org/html/rfc8628 Here you

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

he NxM > problem. > > As such, I would actually suggest constraining this discussion to just the > POP NxM problem rather than NxM in general because, for me at least, the > authZ part of the general case is the most "solved" part of the problem, and > the outstanding

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

> On Feb 25, 2021, at 2:59 PM, Evert Pot wrote: > On 2021-02-25 3:41 a.m., Seán Kelleher wrote: >> Yep, this is the big point - OAuth is designed to require the the third leg >> of trust that creates the NxM problem. >> >> I believe the snippet of Justin's that you quoted actually shows you how

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

I agree that the NxM problem is the purview of the whole IETF, but it’s something that we’re particularly interested in over in GNAP. As the editor of OAuth’s dynamic registration extension and the GNAP core protocol, I hope I can add to this conversation. From a technical standpoint, OAuth’s

Re: [OAUTH-WG] Authorization Header Encoding

dating the Bearer header definition in OAuth 2.1 seems like the > most sensible move. I expect OAuth 2.0 implementers who maintain their > software to pick up the 2.1 spec, sooner or later. > > Vladimir > > > > On 12/02/2021 00:01, Justin Richer wrote: >> The HTTP Working Group

[OAUTH-WG] Digest for DPoP

Two different specifications (GNAP and FAPI signatures) have recently profiled DPoP to use its signature method to protect a different kind of protocol entirely. One thing these methods have in common is that they both define an additional field for holding a digest of the HTTP Message Body:

[OAUTH-WG] Authorization Header Encoding

The HTTP Working Group opened an issue for discussion in relation to the updated HTTP semantics specification. The core of the issue is the format of the “Authorization” header, which of course gets used by the “Bearer” scheme defined in RFC6750. https://github.com/httpwg/http-core/issues/733

Re: [OAUTH-WG] Rich Authorization Requests feedbacks on implementation

Hi Nicolas, > On Jan 10, 2021, at 8:36 PM, Nicolas Mora > wrote: > > Hello, > > I've implemented Rich Authorization Requests defined in > draft-ietf-oauth-rar-03 for Glewlwyd soon-to-be-released 2.5 [1], and I > humbly wanted to write my feedback about this implementation to share my >

Re: [OAUTH-WG] Tenancy in OAuth

Hi Jaap, There have been a number of efforts to address this kind of thing in the OAuth world. You can definitely use a special scope to encode this value, which has the benefit of fitting into the implementation limitations of nearly all OAuth systems out there. The “resource” parameter can

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

I went and implemented this proposal of including a token hash in both an AS (java) and client (javascript) on a system that was already using DPoP and OpenID Connect. What I did there was just use the existing code we had on the AS-side to calculate the “at_hash” in the ID Token from OIDC,

Re: [OAUTH-WG] Token substitution in DPoP

ltrate them in conjunction >>with a token. These stolen artifacts can later be used together >>independent of the client application to access protected resources. >> The impact of such precomputed DPoP proofs can be limited somewhat by >>a browser-b

Re: [OAUTH-WG] Token substitution in DPoP

zation grant and not the > client's key. Therefore, a client may use a different key per token. At least > this is an approach we are following. > > Best, > Nikos > > -Original Message- > From: OAuth On Behalf Of Justin Richer > Sent: Friday, November 20, 2020 9:

[OAUTH-WG] Token substitution in DPoP

While working on an implementation of DPoP recently, I realized that the value of the access token itself is not covered by the DPoP signature at all. What I’m wondering is whether or not this constitutes an attack surface that we care about here. Here’s how it works: Let’s say that a client

Re: [OAUTH-WG] [JAR] scope parameter outside request object of OIDC request

In my opinion, all parameters should be able to be passed inside the request object, including `scope`. We couldn’t do that kind of thing in OIDC because that would be a breaking change to existing requirements in OAuth 2. JAR is taking the step of overriding those requirements, and so it

Re: [OAUTH-WG] WGLC Review of PAR

Nice work, Brian. Looks good to me! From: Brian Campbell [bcampb...@pingidentity.com] Sent: Wednesday, September 2, 2020 3:41 PM To: Justin Richer Cc: Takahiko Kawasaki; Torsten Lodderstedt; oauth Subject: Re: [OAUTH-WG] WGLC Review of PAR Thanks Torsten

Re: [OAUTH-WG] WGLC Review of PAR

seful in situations where client ids and correspoding credentials and > policies are managed by a trusted 3rd party, e.g. via client certifiates > containing client permissions. Such an externally managed client could > interact with an AS trusting the respective 3rd party wit

Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ?

I’m not sure that adding this amount of text to the privacy considerations section is appropriate for an errata. If we wanted to do this, I believe we’d need to do a new revision of 7662. — Justin > On Sep 2, 2020, at 4:39 AM, Denis wrote: > > Hi Ben, > > This new thread, i.e."Towards an

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

hen the user is using > the client. If this implication is not acceptable, implementers can use > other means to carry > access token data, e.g. directly transferring the data needed by the RS > within the access token. > ᐧ > > On Thu, Aug 27, 2020 at 7:19 AM Justin Richer

Re: [OAUTH-WG] WGLC Review of PAR

I completely agree with the utility of the function in question here and it needs to be included. I’m in favor of creating a dedicated section for redirect_uri management, so that we can explain exactly how and why to relax the requirement from core OAuth. In addition, I think we want to

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

I would clarify that this doesn’t necessarily say that the user’s there, and remove the normative requirement (which doesn’t have enforceable teeth in this context): Implementers should be aware that a token introspection request lets the AS know when the client (and potentially the user)

Re: [OAUTH-WG] WGLC Review of PAR

with lots of content that needs no further discussion removed). > > A TL;DR for the WG is that I'd like to get some wider feedback on the > question of changing the one-time-use condition on the request_uri from a > SHOULD to a MUST. > > On Tue, Aug 25, 2020 at 4:57 PM Just

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

I would argue that by the nature of OAuth tokens not being bound to user presence or sessions, it’s not an indication that the user is present necessarily, unless you know something additional about the nature of the client. But it does tell the AS when the client is active for a particular AS,

Re: [OAUTH-WG] WGLC Review of PAR

gt; > On Wed, Aug 19, 2020 at 2:06 PM Justin Richer <mailto:jric...@mit.edu>> wrote: > I’ve done a full read through of the PAR specification, and here are my notes > on it. > > For additional context, I’ve implemented this specification for both a client > and a server

[OAUTH-WG] WGLC Review of PAR

I’ve done a full read through of the PAR specification, and here are my notes on it. For additional context, I’ve implemented this specification for both a client and a server in a couple of languages. Overall, I think it’s in good shape and it makes sense from a developer’s perspective. I’ve

  1   2   3   4   5   6   7   8   9   >