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

see how signing the JWT would make the trust by the TTS towards > the client unnecessary. > > > > Best regards, > > Kai > > > > *From: *OAuth on behalf of George Fletcher > > *Date: *Monday, 22. April 2024 at 17:50 > *To: *Kai Lehmann > *Cc: *

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

r less already concluded, I hope that the spec > can at least allow alternatives. > > > > BR, > > Kai > > > > > > *From: *George Fletcher > *Date: *Friday, 12. April 2024 at 19:53 > *To: *Atul Tulshibagwale > *Cc: *Brian Campbell , Kai Lehmann < &

Re: [OAUTH-WG] [External Sender] Comments on draft-ietf-oauth-transaction-tokens-01

Hi Joe, Thanks so much for the review. Comments inline (I'm only addressing some in this email:) On Wed, Apr 10, 2024 at 11:44 PM Joseph Salowey wrote: > I have reviewed the Transaction Token document. In general I think it is > a needed document and I am glad there is work in this area. I

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

Atul has submitted this PR to address this issue. https://github.com/oauth-wg/oauth-transaction-tokens/pull/90 On Fri, Apr 12, 2024 at 12:10 PM Atul Tulshibagwale wrote: > Thanks all, for your input. We discussed alternatives on a call last week >

[OAUTH-WG] Draft 01 of Transaction Tokens posted

Just a quick note to say that draft 01 of the Transaction Token spec has been posted to the data tracker. https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/ Thanks, George __ The information contained in

[OAUTH-WG] [OAuth Transaction Tokens] PR #57 Update

Hi, I've updated PR #57 [1] to address the following issues: Issue #56 [2] - RFC 9493 and sub_id formats Issue #58 [3] - Authorization details presentation and processing Issue #60 [4] - Use of actor_token and actor_token_type Issue #61 [5] - How is the purp claim of the Txn-Token defined? [1]

[OAUTH-WG] Update and issues with the current transaction token draft

Hi, Based on feedback from a number of you, I've submitted a PR to the OAuth Transaction Token draft to clarify how transaction tokens are requested and obtained. You can find the PR here [1]. I've also created a number of new issues based on this work: 1. RFC 9493 and sub_id formats [2] 2.

Re: [OAUTH-WG] [External Sender] Transaction Tokens draft questions

Hi Ken, My apologies on the slow feedback. Comments inline... On Fri, Dec 1, 2023 at 12:16 PM Ken McCracken wrote: > Hi, > > Thanks for the introduction in previous WG calls. I am interested in > providing Workload call chains in OAuth tokens, and based on >

[OAUTH-WG] DPoP and Dynamic Client Registration

Hi, Are there any best practices for clients that want to use Dynamic Client Registration and plan to register a public key (rather than receiving back a shared client_secret), to use DPoP to prove possession of the matching private key and also integrity protect the JSON object passed to the

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

I'm supportive of adoption On Tue, Nov 14, 2023 at 7: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/ >

Re: [OAUTH-WG] [External Sender] Call for adoption - Transaction Tokens

I'm supportive of adoption :) On Tue, Nov 14, 2023 at 7:58 AM Rifaat Shekh-Yusef wrote: > All, > > This is an *official *call for adoption for the *Transaction Tokens * > draft: > > https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/ >

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

Hi Justin, Whether the scopes are known or unknown to the developer, I don't think it changes the "attack vector" which is to get the client to request more privilege than it should in a given circumstance. Maybe the attacker has a way to capture the token once it issues (this of course can be

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

Hi Atul, I think this is the beginning of a really interesting discussion. I'm wondering if we should start a different thread. The recent OAuth Step-up spec could help in this regard and static RS documentation could be used to describe which scopes are needed for which endpoints. However, as we

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

I support adoption On Wed, Aug 23, 2023 at 3:02 PM Rifaat Shekh-Yusef wrote: > All, > > This is an official call for adoption for the *Protected Resource > Metadata* draft: > https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/ >

Re: [OAUTH-WG] [External Sender] Re: OAuth Trust model

On Thu, Aug 10, 2023 at 4:30 PM Hans Zandbelt wrote: > On Thu, Aug 10, 2023 at 9:40 PM George Fletcher 40capitalone@dmarc.ietf.org> wrote: > >> Hi Matthias, >> >> First, OAuth is about authorization and NOT authentication. If you are >> concerned with Authe

Re: [OAUTH-WG] [External Sender] Re: OAuth Trust model

Hi Matthias, First, OAuth is about authorization and NOT authentication. If you are concerned with Authentication then this thread should move to the OpenID Connect working group mailing list :) Second, if I'm understanding the problem correctly, the issue is NOT with OAuth (the protocol) or the

Re: [OAUTH-WG] [External Sender] Re: IETF OAuth WG Virtual Office Hours

> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!PIOP6Ps-tguAybf6Wyryi22YlsRMAMYBlGyZHjlVyY9kAkCCh6KvGUwF7ZgREPN5jCIO2WlQAAvGXszG_y8d-CmJt9wzazAsXFA$ > -- [image: Capital One] George Fletcher (he/him) Executive Distinguished Engineer • Identi

Re: [OAUTH-WG] [External Sender] Re: Feed back on draft-sh-rats-oidc at-00

i, Jul 28, 2023 at 11:30 PM Smith, Ned wrote: > George, > > Thanks for the detailed responses. I have a few questions / comments > inline. > > Thanks, > > Ned > > > > *From: *George Fletcher > *Date: *Friday, July 28, 2023 at 11:47 AM > *To: *"Smith, Ned&q

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

I support adoption. I hope we consider a lot of the points raised in the discussion that the “attestation” is useful in many contexts and not just “client authentication” at the /token endpoint. Thanks, George On Sat, Jul 29, 2023 at 3:27 PM Rifaat Shekh-Yusef wrote: > All, > > This is an

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

fa-1acXzS4XB2ig8SrMoLTrb4vb_r_uxZt2cpjg3_VjEwxkfOdC8LReNBhwz3s2GIbQWjAR7T2BK25l3OfYw$> >> > ___ > OAuth mailing list > OAuth@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!KTY6C

[OAUTH-WG] Feed back on draft-sh-rats-oidc at-00

by the client. Thanks, George -- [image: Capital One] George Fletcher (he/him) Executive Distinguished Engineer • Identity Architect [image: address]8020 Towers Crescent Drive, Vienna, VA 22128 [image: mobile]616-498-8240 assistant: [image: email] genevieve.mor...@capitalone.com

Re: [OAUTH-WG] [External Sender] Re: Collective name for attacks on cross-device flows: Cross-Device Consent Phishing (CDCP)

I'm a +1 for the name On Thu, Jun 15, 2023 at 11:04 AM Aaron Parecki wrote: > I like it, it's definitely the best out of the list. > > Aaron > > On Thu, Jun 15, 2023 at 7:57 AM Pieter Kasselman 40microsoft@dmarc.ietf.org> wrote: > >> Hi folks, one of the discussion points at IETF 116 for

[OAUTH-WG] Native Apps UX and HTML alternatives

I'm trying to catch Justin's attention with that subject header :-) This is more just for historical purposes. The desktop AOL client was basically a rendering engine of a binary protocol called FDO (two versions 88 and 91). This protocol supported both markup and scripting optimized for transfer

Re: [OAUTH-WG] OAUTH for Web Proxy authentication

To my knowledge that spec doesn't exist. I'll let others chime in if they have seen a proposal in that regard. In regards to which working group, given the core topic is OAuth authorization, I would present it here at a minimum. Thanks, George On 1/22/23 7:06 AM, Markus PlusNet wrote: Dear

Re: [OAUTH-WG] [EXTERNAL] Re: Device Authorization Grant and Illicit Consent Exploits

I just want to make a quick comment on the use of "proximity and location information". I used the device flow to authorize my son's device by having him text me the code so I could login on my device (in a different state) and provide his device access. If we close the door too much we will

Re: [OAUTH-WG] proof of access token possession using client secret

You could require client authentication via the allowed OAuth mechanisms on all resource requests. I think there is some danger in sending the client_secret across the wire on all requests even if the endpoints are all part of the same service. I'd recommend looking at DPoP [1]. Thanks,

Re: [OAUTH-WG] DPoP and client registration metadata

On 2/17/22 4:32 PM, Brian Campbell wrote: On Thu, Feb 17, 2022 at 12:28 PM George Fletcher wrote: Given that the FAPI 2 baseline is requiring either DPoP or MTLS as the sender-constraining methods, I think we need to provide more guidance about how DPoP is used in cases outside

Re: [OAUTH-WG] DPoP and client registration metadata

From an authorization server perspective, I think it makes sense to be able to flag certain clients as only supporting DPoP bound tokens and hence rejecting any request without the appropriate proof. Given that the FAPI 2 baseline is requiring either DPoP or MTLS as the sender-constraining

Re: [OAUTH-WG] DPoP and OpenID Connect

It's probably better to post this question in the OIDC working group email list or file an issue with OpenID Connect. I think it is an interesting and relevant question. OpenID Connect does define the 'private_secret_jwt' mechanism which can be used for client authentication and could be

[OAUTH-WG] DPoP proof and the public key

Hi, I'm going to expose my ignorance here... but what is the rationale for requiring the public key in every DPoP proof? Is there a security reason? or is it for ease of development? If large RSA keys are being used, that public key is rather large for sending with every request when even a

Re: [OAUTH-WG] Token Revocation error codes

message to the server saying “hey I’m done with this token, you can throw it out too”. If the server does revoke the token, the client throws it out. If the server doesn’t revoke the token? Then the client still throws it out. Either way the results from the clie

Re: [OAUTH-WG] Call for adoption - JWK Thumbprint URI

+1 for adoption On 1/13/22 9:26 AM, Rifaat Shekh-Yusef wrote: All, This is a call for adoption for the *JWK Thumbprint URI* draft: https://datatracker.ietf.org/doc/draft-jones-oauth-jwk-thumbprint-uri/ Please, provide your feedback on the mailing list by *Jan 27th*. Regards,  Rifaat & Hannes

Re: [OAUTH-WG] Virtual office hours

Is there a link to a calendar I can pull into my master calendar? That would be really helpful :) On 1/10/22 8:14 AM, Rifaat Shekh-Yusef wrote: The virtual office hours are on Wednesday at 12:00pm Eastern Time. Regards,  Rifaat On Mon, Jan 10, 2022 at 1:03 AM Mike Jones wrote: Are

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

5. Januar 2022 13:44 *An:* Benjamin Häublein *Cc:* George Fletcher ; oauth@ietf.org *Betreff:* Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF Sie erhalten nicht oft E-Mail von "wpa...@rhosys.c

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

My guess is that for an Authorization Server that doesn't receive a 'code_challenge' and 'code_challenge_method' as part of the authorization request, they treat the request as a non-PKCE authorization request. Therefore when the 'code_verifier' is presented at the /token endpoint, the AS

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks

Given the attack is based on a successfully registered callback URL that is malicious, we can also look to the Authorization Server to run more checks on the registered callback URLs (e.g. check against the "unsafe" URL list). Not a 100% solution by any means but could help with reduce the

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

Just curious where this landed? Was it adopted by the WG? I'm ok with adopting it. We will just need to be clear about the overlap with DPoP and determine if guidance is necessary for when to use which method. Thanks, George On 7/30/21 3:26 PM, Aaron Parecki wrote: I support the adoption of

Re: [OAUTH-WG] Purpose of client authentication for "public" client types

While not widely deployed, the OAuth2 solution to a deployment of "public clients" that need to be able to transition to "confidential clients" so that client authentication makes sense, is to use Dynamic Client Registration (RFC 7591). Dynamic Client Registration allows the public client to

Re: [OAUTH-WG] DPoP key rotation

There has also been some limited discussion on whether it's useful for mobile applications to create a relationship between keys used for Dynamic Client Registration (DCR) and the associated keys for DPoP headers. DCR does have mechanisms for rotating client instance keys and hence if the keys

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-17.txt

While this is mostly covered in section 8.6 of RFC 8252 for native apps, I wonder if we shouldn't mention "Client Impersonation" in this doc as well in that any public client can be easily impersonated. Mobile OS's are providing additional mechanisms for "authenticating" the client but it's

Re: [OAUTH-WG] Authorization handover from mobile app to website

he web session.  TOC  5. Normative References [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). [RFC6749] Hardt, D., “The OAuth 2.0 Authorization Framework,” RFC 6749, October 2012 (TXT). [RFC

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Unfortunately, in the mobile app world this isn't sufficient. On iOS using Universal Links will bind the https redirect_url to your app in a secure way but it doesn't work the same way on Android with App Links. There is still a problem with "mobile app impersonation". If you have an app that

Re: [OAUTH-WG] Your opinion about draft-ideskog-assisted-token

Hi Adrian, I agree with Brian that the proposed document directly relates to ongoing work in the OAuth working group. Establishing a completely different mechanism for supporting Single Page Apps other than what is being proposed by the working group will lead to bifurcated implementations

Re: [OAUTH-WG] Android App Links (AKA Universal Links)

6099813001/ Joseph On 3 Nov 2020, at 22:12, George Fletcher wrote: I sent in some notes but I don't have a link for the recording. I don't believe the recordings were being kept much past the end of the conference. I'm pretty sure I heard that the recordings would be removed after N days (I don't

Re: [OAUTH-WG] Android App Links (AKA Universal Links)

than I could have given and matches my understanding as well. Thanks, George On 11/3/20 2:13 PM, Dick Hardt wrote: Thanks Joseph. George Fletcher ran a great session on the topic at the last IIW as well. George: do you have a link? ᐧ On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan wrote: Hi

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

The issue I see with sticking with the DPoP token_type is that from a roll_out perspective, ALL resource servers must be updated to support the new scheme and only then can the DPoP deployment start. For any wide ecosystem deployment that can be problematic. I don't have any great

Re: [OAUTH-WG] Caution about open redirectors using the state parameter

+1 However, we should be careful how we prohibit it... because if the state value is actually signed, having the URL there isn't a problem as the attacker can not manipulate the value without breaking the signature. On 4/20/20 5:28 PM, Mike Jones wrote: I've seen several circumstances where

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

This brings up interesting rollout questions. Protecting just the refresh_token is easy and a useful security measure (especially if access tokens are short lived). However, once you start issuing DPoP bound access tokens to a client, it means ALL the endpoints that client invokes MUST

Re: [OAUTH-WG] PAR and client metadata

f. Another question is whether this request_uri must be PAR based or whether it could be any other request_uri. On 16. Apr 2020, at 23:05, George Fletcher wrote: Maybe if we make it an array of authorization "flows" supported? A bit like the AS can describe whether it supports "pa

Re: [OAUTH-WG] PAR and client metadata

Maybe if we make it an array of authorization "flows" supported? A bit like the AS can describe whether it supports "pairwise", "public" or both? Not sure what to name it though:) Possible values could be "redirect" and "par" (redirect not being quite right:) which allows for expansion in the

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

Hi Denis, If the same token is used (within a session) for multiple API calls then all those API calls can be correlated together even if the token does not have a 'sub' claim because the token itself is the correlating identifier (same is true for the session identifier). In regards to the

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

On 4/14/20 10:23 AM, Denis wrote: Unfortunately, this is not possible since RFC 7519 (4.1.2) states:     The subject value MUST either be scoped to be *locally unique in the context of the issuer or be globally unique*. Regarding this phrase from RFC 7519, I don't agree that it prevents

Re: [OAUTH-WG] oauth-browser-based-apps-05 - BFF

Sorry to have missed the meeting. To your second point, I think we should provide guidance in this area. Currently section 6.2 requires all requests to be proxied via the application server. Should we add an additional section for the use case Vittorio mentions? Also there is no mention of

Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

pends on the modeling of the domain specific problem the developer is tackling. The highest order bit is that if two entities (API, etc.. intended token recipients) have different security characteristics (e.g. leaking a token for one has different consequences than if you'd leak a token for

Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

warning rather than a security feature clamored for- if the language is problematic I’d be more inclined to take the sentence out rather than complicating the guidance further. From: Brian Campbell Sent: Wednesday, March 25, 2020 11:21 AM To: George Fletcher Cc: Brian Campbell ; Vit

Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Can we not use the 'kid' claim to inform the RS as to which key is being used? What am I missing? On 3/25/20 1:51 PM, Brian Campbell wrote: I think, even without that statement in the draft, that ASes already have license to use different keys if they so choose. And maybe I'm not creative

Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

stuffing. From: OAuth on behalf of George Fletcher Date: Tuesday, March 24, 2020 at 11:48 To: Vittorio Bertocci , Takahiko Kawasaki Cc: oauth Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Focusing just on this comment... This assumes the s

Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Focusing just on this comment... This assumes the system uses a specific implementation of scopes values (e.g. 'read', 'write', 'delete'). It is very possible that in the context of a calendar services and an inbox service... the system defines scopes like 'cal-r', 'cal-w', 'mail-r', mail-w'

Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Feedback on the spec... Section 1. Introduction ��� second line: scenario should be plural --> scenarios ��� second sentence: "are not ran by" --> "are not run by" Section 2.2.1 Authentication Information Claims ��� I'm not sure that this definition of `auth_time` allows for

Re: [OAUTH-WG] Call for Adoption: DPoP

+1 On 3/23/20 1:57 PM, Vittorio Bertocci wrote: +1 On Tue, Mar 17, 2020 at 8:16 AM Mike Jones wrote: I am for adoption of DPoP. -- Mike *From:* OAuth *On Behalf Of * Rifaat Shekh-Yusef *Sent:* Tuesday, March 17, 2020 5:21 AM

Re: [OAUTH-WG] First Draft of OAuth 2.1

I also am in favor of not requiring "sender constraint" as a MUST. SHOULD or RECOMMENDED is fine. Many websites are NOT Single-Page-Apps and as such DPOP doesn't work for those environments. Converting all web based environments to SPAs so not viable. Thanks, George On 3/12/20 2:28 PM,

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

I'm a +1 for adding client_id back as well On 3/12/20 11:31 AM, Brian Campbell wrote: +1 (again) that `client_id` should be allowed/required as a query parameter outside the request object JWT or URI and that its value has to be the same as within the request object. On Thu, Mar 12, 2020 at

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.txt

g so would make it one more step removed from easy developer understanding. -- Justin Richer Bespoke Engineering +1 (617) 564-3801 https://bspk.io/ On Sep 24, 2019, at 1:45 PM, George Fletcher mailto:gffle...@aol.com>> wrote:

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt

This is a great point about personal information. However, there are uses for authorization_details that don't specifically relate to personal information. Think an enhancement that has language preference, maybe a device identifier. Maybe we can add more text in the security considerations

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt

Just two questions... 1. What is the rationale that 'data' is really an array of arbitrary top-level claims? I find looking at the spec and not finding a 'data' section a little confusing. 2. What is the rationale for sending the JSON object as a urlencoded JSON string rather than a

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-reciprocal-04

Reciprocal OAuth - draft 04 Feedback 2.1 Reciprocal Scope Request -- The spec assumes the reader has an strong understanding of RFC 6749 and just references sections. More prose should be added to get the reader a better understanding of what is happening and then reference the normative text

Re: [OAUTH-WG] Refresh tokens

For historical references only... the Google model around refresh tokens and the AOL model around refresh tokens were slightly different. So I proposed a bunch of the OIDC text around refresh tokens and offline access to allow for both models. At AOL, the model was that refresh_tokens were

Re: [OAUTH-WG] Refresh tokens

I'll just add a couple more thoughts around refresh_tokens. 1. I agree with David that refresh_tokens are valuable in an "online" scenario and should be used there. 2. To use a refresh token at the /token endpoint, client authentication is required. This is where it gets difficult for

Re: [OAUTH-WG] Client assertions to endpoints other than the token endpoint

So if by "other endpoints" we mean "other endpoints at the AS" then I think issuer makes a lot of sense and could be recommended value. However, if the client assertion is being sent to an endpoint not managed by the AS, then it should use a value that identifies that "audience". In this

Re: [OAUTH-WG] Transaction Authorization with OAuth

One thing to keep in mind with the "Push Request Object" model and the concept of a more detailed scope structure, if the specified values are not for a single transaction, then the AS will be required to keep the "Pushed Request Object" for the "lifetime" of the access_token and possibly the

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

ge comply with the JWT standards. -- Mike From: Hans Zandbelt mailto:hans.zandb...@zmartzone.eu>> Sent: Thursday, April 4, 2019 12:59 PM To: Mike Jones mailto:michael.jo...@microsoft.com>> Cc: George Fletcher mailto:40aol@dmarc...i

Re: [OAUTH-WG] Transaction Authorization with OAuth

nt. So that might not be the best name. At this point I'm probably splitting hairs:) Naming things is hard:) On 4/30/19 6:39 AM, Torsten Lodderstedt wrote: Am 26.04.2019 um 16:17 schrieb George Fletcher <mailto:gffle...@aol.com>>: On 4/25/19 1:54 PM, Torsten Lodderstedt wrote: Am

Re: [OAUTH-WG] MTLS vs. DPOP

I don't see them the same at all. With MTLS, the token is bound to the transport layer (and the key used to establish that encrypted connection). With DPOP, the token is bound to the private key known to the client. To compromise an MTLS bound token the attacker has to compromise the private

Re: [OAUTH-WG] Transaction Authorization with OAuth (Torsten Lodderstedt)

I agree that we definitely need better definition and guidance around scopes and authorized access patterns. I think what is unique about what Torsten is proposing is that in his case he wants to authorize an individual transaction (not a set of transactions). Normally, with scopes and access

Re: [OAUTH-WG] Transaction Authorization with OAuth

' provided by OAuth2. In this context I like the pushed-request-object method as the resource server is going to need to pull the same transactional requirements when it receives the access token. Thanks, George On 4/26/19 10:17 AM, George Fletcher wrote: On 4/25/19 1:54 PM, Torsten Lodderstedt wro

Re: [OAUTH-WG] Transaction Authorization with OAuth

On 4/25/19 1:54 PM, Torsten Lodderstedt wrote: Am 25.04.2019 um 17:03 schrieb George Fletcher <mailto:gffle...@aol.com>>: A couple of thoughts... 1. It doesn't feel like these are scopes (at least not as scope is defined by RFC 6749). It feels like they are more tr

Re: [OAUTH-WG] Transaction Authorization with OAuth

A couple of thoughts... 1. It doesn't feel like these are scopes (at least not as scope is defined by RFC 6749). It feels like they are more transaction requirements. 2. The schemas are going to be very ecosystem specific, correct? On 4/24/19 1:08 PM, Torsten Lodderstedt wrote: Hi Sascha,

Re: [OAUTH-WG] Transaction Authorization with OAuth

the scope they need, making a lot easier to change RS's access constraints as well as pushing contextual information that could eventually enrich the authorization process. On Mon, Apr 22, 2019 at 4:04 PM George Fletcher <mailto:gffle...@aol.com>> wrote: Speaking just to the UMA side

Re: [OAUTH-WG] Transaction Authorization with OAuth

uma/wg/oauth-uma-grant-2.0-05.html#authorization-assessment>). https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html#seek-authorization On 4/23/19 1:04 AM, Torsten Lodderstedt wrote: Does UMA use the standard scope parameter? Am 22.04.2019 um 21:03 schrieb George Fl

Re: [OAUTH-WG] Transaction Authorization with OAuth

Speaking just to the UMA side of things... it's possible in UMA 2 for the client to request additional scopes when interacting with the token endpoint specifically to address cases where the client knows it's going to make the following requests and wants to obtain a token with sufficient

Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

+1 for me as well :) On 4/8/19 1:38 PM, Hans Zandbelt wrote: +1 Hans. On Mon, Apr 8, 2019, 19:34 John Bradley > wrote: I agree this should be adopted as a working group document. On 4/8/2019 7:07 PM, Hannes Tschofenig wrote: > Hi all, > > this

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

I get your 1st party use case and if you think about a company that might have multiple endpoints on different domains that provide API services all invoked by a mobile app... requiring the mobile app to effectively downscope (or resource indicator bind) tokens means a lot of chatter between

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

that in a way such deployments are already broken e.g. in the typical use case of onboarding client accounts in the same directory/OU/namespace as user accounts and we don't need to cater for that. Hans. On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <mailto:gffle...@aol.com>> wrote:

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

onal specifics for the given application. On Thu, Apr 4, 2019 at 8:07 AM George Fletcher mailto:40aol@dmarc.ietf.org>> wrote: Another comment... aud REQUIRED - as defined in section 2 of [OpenID.Core <https://tools.ietf.

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Another comment... aud REQUIRED - as defined in section 2 of [OpenID.Core ]. See Section 3 for indications on

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

I agree that this will break a lot of existing flows... especially those using any form of the client_credentials flow. In that sense I'm not completely on board yet :) On 3/26/19 12:56 PM, Hans Zandbelt wrote: great summary! this will hurt quite a few existing m2m deployments but I do like

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

ommunicate the DPoP-Proof to the RS. Possibly an example in the session for presenting the token to the RS would help. Thanks, George On 4/3/19 11:39 AM, Daniel Fett wrote: This is fixed in -01: https://tools.ietf.org/html/draft-fett-oauth-dpop-01 -Daniel Am 03.04.19 um 17:28 schrieb Georg

Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00

? Regards. Pedro Igor On Tue, Apr 2, 2019 at 1:10 PM George Fletcher mailto:40aol@dmarc.ietf.org>> wrote: I think it's fair to call it out (either in the paragraph here or in the security considerations). The issue is that the security aspect of the access token end

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

A quick question regarding... o "http_uri": The HTTP URI used for the request, without query and fragment parts (REQUIRED). Is 'without' supposed to be 'with' ? The example shows the http_uri *with* the query parameters :) On 3/28/19 6:17 AM, Daniel Fett wrote: Hi all, I

Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00

ifferently. Is that a fair assessment? I think the fix to this paragraph would be a slight rewording to just remove the mention of public clients. Aaron On Tue, Apr 2, 2019 at 8:53 AM George Fletcher <mailto:gffle...@aol.com>> wrote: Hi, In section 6.2 the followin

[OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00

Hi, In section 6.2 the following statement is made... In this scenario, the backend component may be a confidential client which is issued its own client secret. Despite this, there are still some ways in which this application is effectively a public client, as the end result is

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

The one use case I've run across for introspecting refresh_tokens is to determine the lifetime of the refresh_token (i.e. when it expires). Some authorization servers bind the refresh_token to the user's authentication session and hence they have a defined lifetime. I suppose another use case

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

+1 to using the same client authn method as for the /token endpoint On 3/11/19 12:31 PM, Brian Campbell wrote: On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan > wrote: Strike that, it should maybe just use the registered auth method for the token endpoint?

Re: [OAUTH-WG] Correct error code for rate limiting?

handle the transport conditions correctly. Thanks, George On 2/22/19 10:34 AM, Evert Pot wrote: On 2019-02-22 10:29 a.m., George Fletcher wrote: I believe Torsten proposed an "authentication_failed" error response in a different context. Possibly we could use that? Alternatively, OpenID Con

Re: [OAUTH-WG] Correct error code for rate limiting?

r the HTTP response code, but what about the OAuth error code string? "invalid_grant" seems closest but doesn't sound right because if the app tries the same request again later it would be valid. On Fri, Feb 22, 2019 at 6:02 AM George Fletcher <mailto:gffle...@aol.com>>

Re: [OAUTH-WG] Correct error code for rate limiting?

+1 for using 429 On 2/22/19 2:09 AM, David Waite wrote: I don’t believe that any of the currently registered error codes are appropriate for indicating that the password request is invalid, let alone a more specific behavior like rate limiting. It is also my opinion that 400 Bad Request

Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

possible but in certain scenarios may feel quite unnatural. It must have felt unnatural already to the group when working on the token exchange spec… Ciao Hannes *From:*George Fletcher *Sent:* Donnerstag, 7. Februar 2019 17:06 *To:* Hannes Tschofenig ; Ludwig Seitz ; a...@ietf.org; oauth@ietf.org

Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

er values.  Multiple "audience" parameters may be used to indicate that the issued token is intended to be used at the multiple audiences listed.  The "audience" and "resource" parameters may be used together to indicate multiple target services with a mix of logical n

Re: [OAUTH-WG] [Ace] Resource, Audience, and req_aud

+1 for rationalizing this! :) On 2/7/19 10:24 AM, Hannes Tschofenig wrote: Hi all, after re-reading token exchange, the resource indicator, and the ace-oauth-params drafts I am wondering whether it is really necessary to have different functionality in ACE vs. in OAuth for basic parameters.

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" and just use the normal metadata values? On 1/15/19 8:48 AM, Brian Campbell wrote: It would definitely be optional, apologies if that wasn't made clear. It'd be something to the effect of

  1   2   3   >