[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

> client_credential grant type to add more details on the actual delegation > required and then those details can be passed on to the RO for approval. > The authentication between the AS and the RO for approval requests will > also need some consideration… The only potential drawback i

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

r can > dynamically manage delegation for third party client(s) so that no > additional policies are needed at AS. > > > > *From:* Aaron Parecki [mailto:aa...@parecki.com] > *Sent:* Sunday, 19 May 2024 10:23 PM > *To:* Igor Janicijevic > *Cc:* Warren Parad ; > *Subje

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

hat resource to the third party client, but not the “write” scope. > This means that the third party client will only be able to obtain read > only access to that resource and will not be able to update the resource. > > > > *From:* Warren Parad [mailto:wpa...@rhosys.ch] > *S

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

ss”… > > > > There is no delegated flow for system to system access in the standard > OAuth, as far as I know… > > > > > > *From:* Warren Parad [mailto:wpa...@rhosys.ch] > *Sent:* Sunday, 19 May 2024 9:18 PM > *To:* Igor Janicijevic > *Cc:* Thomas Broyer

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

revoke that > token because it will have to have a possession of it to present it to the > revocation endpoint… Maybe I am completely missing your point, so can you, > please, clarify. > > > > Cheers, > > Igor > > > > > > *From:* Warren Parad [mailto:wp

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

well as > the ability to revoke that delegation at any point in time. This also means > that AS does not need to maintain policy that governs the federation (or > delegation) of access between the clients. > > > > Regards, > > Igor > > > > > > *From:*

[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

That was my first thought, but since we only have one AS, isn't just this just OAuth but switching up which is the RS and which is the user agent? Why wouldn't the third party just request a client_credentials grant for the RS using the appropriate audience? On Sat, May 18, 2024, 16:52 Thomas

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

Some more evidence for this is most of our customers. We provide something a bit different from Hello, but the ask is the same. The branding experience for the widget must be fully controlled by the app developers, this is the only way they'll support it. We have our own unified managed login

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

If someone uses the auth code flow, how would the account chooser display anything? On Fri, May 10, 2024, 18:53 Neil Madden wrote: > > > On 10 May 2024, at 17:07, Sam Goto wrote: > > On Fri, May 10, 2024 at 2:41 AM Neil Madden > wrote: > >> On 9 May 2024, at 21:58, Watson Ladd wrote: >> > >>

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

I think I'm still missing something, and I'm sure it was discussed somewhere and I just didn't see it. How will this help avoid the NASCAR problem, for sites when a user *signs up* or when the user *signs in on a new browser?* On Thu, May 9, 2024 at 1:07 AM Sam Goto wrote: > > > On Wed, May 8,

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

I just marked it as spam, so his domain can deal with that. If everyone does it, the domain may be permanently denylisted. On Sun, May 5, 2024 at 9:50 PM Brian Campbell wrote: > Итак, у нас есть еще девять дней этих сообщений? > > On Sun, May 5, 2024 at 1:02 PM Konstantin Korsakov > wrote: >

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

Some thoughts in no particular order, but mostly I'm with Justin: 1. The exact data properties of the json probably don't belong in this RFC, but rather can be used as an example in the RFC rather than anything normative, as the structure defined herein is not sufficient in many

Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

Sachin, Can I ask what your goal is here, as in what would you like out of this conversation, what concrete if anything would like this working group to action? It seems that you have had a question, which has been answered multiple times (in multiple different email threads, I might add). The

Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

Sachin, Why does it matter what Curity does here? Is the question about what should happen according to the specification or whether or not Curity is compliant with the spec when it comes to refresh tokens? - Warren On Tue, Feb 20, 2024 at 8:27 PM Sachin Mamoru wrote: > Hi Neil, > > Thanks

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

I feel like the source of the confusion might be, *what is the purpose of the statement in the description of this property. e.g. *Why say anything at all? If the description was: OAuth 2.0 client identifier string. An authorization server MAY issue the same client identifier to

Re: [OAUTH-WG] OAuth WG Slack Channel

t Shekh-Yusef < >> rifaat.s.i...@gmail.com> wrote: >> >>> I think all you need is a datatracker account. >>> >>> Regards, >>> Rifaat >>> >>> >>> On Thu, Dec 7, 2023 at 1:16 PM Warren Parad wrote: >>> >>>>

Re: [OAUTH-WG] OAuth WG Slack Channel

t; > On Thu, Dec 7, 2023 at 1:16 PM Warren Parad wrote: > >> I didn't know there was a Slack Workspace for this. How does one get an >> invite to the workspace? >> >> On Thu, Dec 7, 2023 at 7:04 PM Rifaat Shekh-Yusef < >> rifaat.s.i...@gmail.com> wro

Re: [OAUTH-WG] OAuth WG Slack Channel

I didn't know there was a Slack Workspace for this. How does one get an invite to the workspace? On Thu, Dec 7, 2023 at 7:04 PM Rifaat Shekh-Yusef wrote: > All, > > We now have an OAuth channel (#oauth) at the IETF Slack service. > ietf.slack.com > > Feel free to join the channel if you use

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

It goes both ways for me. I hate the fact that eventually there would need to be an exhaustive list of all the things you shouldn't be doing. But I also understand the value in BCPs and direct guidance on footguns and pits of failure. I can totally imagine there is a story behind this errata,

Re: [OAUTH-WG] A Discussion of Multiple Suffixes

 On Fri, Nov 17, 2023, 14:47 David Waite wrote: > wMy concern is higher level, that we may be promoting over-expression of > types. > > My interpretation of historical decisions/retconning was that +xml made > sense because XML documents form an object model that can be processable >

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

> > the resulting consent dialog from Google is going to say "Apple is > requesting super admin privileges to your Apple account". And that's totally fine (also assuming you meant *to your google account*. But the second provider MUST also have a prompt to the delegation of those resources. That

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

For (1) arguably these are different resources, therefore, they of course have different paths. The draft specifically outlines that each of them can have their own metadata document: https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-00.html#name-protected-resource-metadata- If

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

t time and '(authorization > server)' in parentheses the second time. > > > > > > -- > > Wilhelm > > > > *Von:* Warren Parad > *Gesendet:* 17 September 2023 12:51 > *An:* Aaron Parecki > *Cc:* RFC Errata System ; w.fas...@gmail.com; > oauth@ietf.o

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

It does look confusing if we only look at that one sentence, but as soon as you pull in the whole paragraph, it seems pretty clear https://www.rfc-editor.org/rfc/rfc6749 > For example, an end-user (resource owner) can grant a printing >service (client) access to her protected photos stored

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

Arguably the client can't revoke the token. It can request to revoke the token and then the decision of whether it is revoked is only on the AS. A client considering a token revoked has no merit on the value of the *active *flag. For full context, this is the section:

Re: [OAUTH-WG] OAuth Trust model

t is out of scope for now. > > I don't have this ready. I'm only answering this group about this > possibility, but I can work with the group about this. > > > Em ter., 15 de ago. de 2023 às 14:59, Warren Parad 40rhosys...@dmarc.ietf.org> escreveu: > >> I think th

Re: [OAUTH-WG] OAuth Trust model

>> On Thu, Aug 10, 2023 at 2:59 PM Matthias Fulz wrote: >> >> I can follow your point but please try to think from a different >> perspective: >> >> As authorization protocol, how can it not let the user decide which AS is >> AUTHORIZED at which RS acting as the user

Re: [OAUTH-WG] OAuth Trust model

> > I'm not sure how to explain the main concern about this in more detail and > of course I can avoid services providing these type of logins without my > permission, but as said what about the future? > On 8/10/23 00:40, Warren Parad wrote: > > Let me try that differently, is OAu

Re: [OAUTH-WG] OAuth Trust model

en there's the question of why don't providers just implement a FIDO2 compliant strategy. Wouldn't that solve everything? On Thu, Aug 10, 2023 at 12:27 AM Matthias Fulz wrote: > Thank you for the responses so far. > On 8/9/23 22:20, Warren Parad wrote: > > I can tell you I definitely re

Re: [OAUTH-WG] OAuth Trust model

I can tell you I definitely read it. I actually read it multiple times. But I don't know what to tell you. The problem you've identified exists, but that doesn't necessarily mean it is a problem. In a way it is a bit like, You create a bank account at a bank and you give them all your money. They

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

+1 On Sat, Jul 29, 2023 at 9:26 PM Rifaat Shekh-Yusef wrote: > All, > > This is an official call for adoption for the *SD-JWT-based Verifiable > Credentials *draft discussed in SF. > https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/ > > Please, reply on the mailing list and let us

Re: [OAUTH-WG] BCP: Mix-Up Attacks, Implicit Grant Variant

That doesn't make sense to me. On Wed, Jun 14, 2023, 21:31 Daniel Fett wrote: > Hi Alexander, > Am 14.06.23 um 15:19 schrieb Alexander Rademann: > > *Hello, everyone! Section 4.4.1 of the BCP > > draft

Re: [OAUTH-WG] BCP: Mix-Up Attacks, Implicit Grant Variant

Presumably, the attacker can get the token by having the Honest-AS redirect the user to a site controlled by the Attacker. That site then would redirect the user back to the original site with the Honest-AS token. This is no different than an ordinary phishing based attack. On Wed, Jun 14, 2023,

Re: [OAUTH-WG] OAuth 2.1 & B2E apps (Jaap Francke)

Frankly I just don't understand. You've even said in your original email, that the oath spec is alive and well in enterprise deployments. And since that is the case, it points to how successful the current state of the RFCs are. So I can't fathom what would make sense to actually change. If

Re: [OAUTH-WG] A proposal for a new Internet Draft

. On Sun, Apr 2, 2023 at 11:53 PM Clinton Bunch wrote: > On 4/2/2023 4:44 PM, Warren Parad wrote: > > If CalDAV is that spec, then wouldn't it make sense to request updates to > that spec to additionally define OAuth scopes? I don't think it makes sense > for the OAuth WG to define s

Re: [OAUTH-WG] A proposal for a new Internet Draft

mantics are not quite well-defined > enough, that would be the point of having a discussion. > > > That is to say, a spec needs to exist before creating scopes, and if the > spec did exist, the scopes would already be defined. For the that reason, I > don't believe this this the best wor

Re: [OAUTH-WG] A proposal for a new Internet Draft

or that. On Sun, Apr 2, 2023 at 10:53 PM Clinton Bunch wrote: > On 4/2/2023 3:13 PM, Warren Parad wrote: > > I'm looking for proof that anyone actually needs these. Introducing > unnecessary scopes into the spec is both a waste of time and needlessly > complicates the documen

Re: [OAUTH-WG] A proposal for a new Internet Draft

about expanding scopes in a way that currently isn't used. Which brings us back to, what problem are you trying to solve? On Sun, Apr 2, 2023 at 9:57 PM Clinton Bunch wrote: > On 4/2/2023 2:49 PM, Warren Parad wrote: > > But why these scopes? > > Separate read and write scopes for t

Re: [OAUTH-WG] A proposal for a new Internet Draft

But why these scopes? On Sun, Apr 2, 2023 at 9:37 PM Clinton Bunch wrote: > > > On 4/2/2023 2:26 PM, Warren Parad wrote: > > Sorry, I'm asking why these scopes at all? I personally have never seen > any of them used ever (and I'm not being hyperbolic), H

Re: [OAUTH-WG] A proposal for a new Internet Draft

Sorry, I'm asking why these scopes at all? I personally have never seen any of them used ever (and I'm not being hyperbolic), How did you come up with these suggestions? On Sun, Apr 2, 2023 at 8:46 PM Clinton Bunch wrote: > On 4/2/2023 1:34 PM, Warren Parad wrote: > > I propose a se

Re: [OAUTH-WG] A proposal for a new Internet Draft

> > I propose a set of nine well-known scopes Can you elaborate on what you mean by "well-known"? Is there some canonical list, where these were pulled from? - Warren On Sun, Apr 2, 2023 at 8:12 PM Clinton Bunch wrote: > This seemed the most appropriate working group to post this suggestion.

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

It requires third party cookies which most browsers block by default, and doesn't this assume that the cookie is set to *SameSite=Loose *or *SameSite=None*. Wouldn't that directly expose that cookie for malicious sites to utilize it to steal connect2Id generate access tokens? Also what I don't

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

Markus could you shed some light on how this would be different from the normal OAuth flow between any resource server and the user agent? Proxies today could already start accepting OAuth authorization following the OAuth spec, right? On Tue, Jan 31, 2023 at 12:48 AM Markus wrote: > Hi Rifaat,

Re: [OAUTH-WG] Proposal for new OAuth authorization grant

I didn't think this all the way through, but my immediate thought is, doesn't the JWT Bearer directly support this already: https://www.rfc-editor.org/rfc/rfc7523 It's not an exact match but I believe most if not all of it follows pretty well. If it doesn't, it might be interesting to improve the

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

I support the adoption of this document. On Tue, Nov 15, 2022 at 3:43 PM Rifaat Shekh-Yusef wrote: > All, > > During the IETF meeting last week, there was a strong support for > the adoption of the following document as a WG document: >

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

Hello Sabrina, In the future I want to make sure that there is more than one owner for this process. In the past it sometimes was quite a challenge to get timely approvals. Would you be able to point me to the right place to ensure we can extend the ownership? Thanks, Warren On Thu, Nov 17,

Re: [OAUTH-WG] [EXT] Re: Fw: New Version Notification for draft-burgin-jenkins-identity-chaining-00.txt

ould with embedded tokens > > 2. Our solution puts the burden of adding additional logic in the AS > instead of the PRs as embedded tokens would do. > > > > Kelley > > > > *From: *Atul Tulshibagwale > *Date: *Friday, November 11, 2022 at 9:54 AM > *To:

Re: [OAUTH-WG] Fw: New Version Notification for draft-burgin-jenkins-identity-chaining-00.txt

I think it would be confusing for implementers to have to figure out the difference between this implementation and https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt. This previous one looks to add the exact same information but seems to have a more robust encapsulation mechanism.

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

Section 5 of the draft RFC which acknowledges the existence of loops being >> handled by OIDC specs. >> >> The recommended behavior will help prevent clients getting stuck in a >>> loop where the authorization server keeps returning tokens that the >>> resource server alr

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

app > > Wishing everyone a Happy Diwali > > > > On Sat, Oct 22, 2022 at 12:49 AM Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >> Thanks Warren, it's a good reminder about REQUIRED/MUST/etc meaning in >> the context of the given document. >>

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

REQUIRED always means "in the context of the RFC". I fully agree to your statement that 'existing implementations aren't > expected to comply with the new specification'. However, the point I am > making is that we cannot be biased towards OIDC specifications and leave > others non-compliant. We

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

inning. > > Similar to how the work on TLS 1.3 didn’t stop people from specifying new > capabilities for TLS 1.2, I don’t think the eventual goals of JWP+JPT > should detract from specifying SD-JWT. > > -DW > > On Aug 5, 2022, at 3:28 AM, Warren Parad 40rhosys...@dmarc.ie

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

ns that have been previously outlined in this thread. > > ------ > *De :* OAuth de la part de Warren Parad 40rhosys...@dmarc.ietf.org> > *Envoyé :* vendredi, août 5, 2022 6:25 AM > *À :* Daniel Fett > *Cc :* oauth@ietf.org > *Objet :* Re: [OAUTH-WG] Ca

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

t there yet. > > But, SD-JWT is not in production yet. If the OAuth WG decides that > substantial changes are required, now is the best time for that. > > Also, I wanted to highlight with my statement that SD-JWT is easy to > implement due to its simplicity. > > -Daniel > &g

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

n why a WG that seems like the appropriate one, thinks it wouldn't make sense. If it is just a matter of timing, then whatever. But if there are concrete recommendations from that group, I would love to hear them. On Fri, Aug 5, 2022 at 10:26 AM Daniel Fett wrote: > Am 05.08.22 um 10:22 schrieb

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

xactly. Because there is no perfect solution, but only one that >> compromises one feature for another. So in the end if the users decide >> which is preferrable, it will mean that usability wins and trumps security >> and privacy concerns!! If service providers decide they may opt

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

> user/wallet has an access token for a complete verifiable credential, then > it should be able to ask for a set of subset credentials either > concurrently or sequentially, dependent upon the policy of the RS. > > Does this make sense to you now? > > Kind regards > > Da

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

er stories. On Tue, Aug 2, 2022, 11:47 Torsten Lodderstedt wrote: > > Am 02.08.2022 um 11:06 schrieb Warren Parad : > > I was following your train of thought, let me paste that here for > transparency, you specifically said: > >> In an OAuth scenario, the user‘s walle

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

about a different point? On Tue, Aug 2, 2022 at 10:54 AM Torsten Lodderstedt wrote: > > > Am 02.08.2022 um 10:48 schrieb Warren Parad 40rhosys...@dmarc.ietf.org>: > >  > Can you please reread what you wrote and rephrase it differently? Telling > us to look at the OAuth JWT R

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

What does that look like? On Tue, Aug 2, 2022 at 10:44 AM Torsten Lodderstedt wrote: > > > Am 02.08.2022 um 10:35 schrieb Warren Parad 40rhosys...@dmarc.ietf.org>: > >  > Why would we not include those seemingly critical details in the draft > then? > >

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

the AS wouldn't be able to do this. On Tue, Aug 2, 2022 at 10:14 AM Torsten Lodderstedt wrote: > > > Am 02.08.2022 um 09:53 schrieb Warren Parad 40rhosys...@dmarc.ietf.org>: > >  > If we are in a offline scenario how does the verifier got ahold of the > public key associate

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

If we are in a offline scenario how does the verifier got ahold of the public key associated with the id token? They would need to be online, that defeats any benefit this could provide. Or what if the token you have expires. Many providers issue tokens only good for 1 hour. If that expires, the

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

The ISO mDL selective disclosure is more privacy protecting than the >>> proposed SD-JWT because it also blinds the property names as well as the >>> values. >>> >>> The examples below do not say why the use cases cannot work if the >>> wall

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

ntly to requests >>> for age-over from two people of the same age. >>> >>> The ISO mDL selective disclosure is more privacy protecting than the >>> proposed SD-JWT because it also blinds the property names as well as the >>> values. >>> >

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

> > This is done because network availability and privacy concerns may > separate the act of acquiring the SD-JWT of a license from the issuing > authority, and presenting it (such as days later during a traffic stop on a > mountain road). I think we keep pointing to "offline drivers license" as

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

I too do not support adoption. Something is "off" for me, I don't quite get the expectation on the secure flow, in this draft, doesn't the issuer have to know the claims that could be requested up front? If the goal is to not have the issuer contain any of this data, but let the holder "add in

Re: [OAUTH-WG] How can we define a parameter to be both OPTIONAL and REQUIRED at the same time

Can you explain why you think: > > But definitely cannot be both (as in the present definition). >From a theoretical perspective, of course it can be. But perhaps there is a concrete reason you think otherwise, I think it would be prudent to share that context explicitly with an explanation

Re: [OAUTH-WG] [EXT] Re: MITRE Updated Token Chaining Profile for Multi ICAM Ecosystems

nge for our use cases while adding in new requirements from OAuth 2.1. > > > > For those of you who have seen my “Token and Identity Chaining Between > PRs” documents and/or presentation, do you think this is a viable option? > > > > Regards, > > Kelley > > >

Re: [OAUTH-WG] DPoP with token exchange where the subject_token and / or actor_token is also DPoP bound

also "addressed" as a DPoP aware protected > resource. > > If only one DPoP HTTP header is permitted one work around I see is to > insist on a single DPoP proof for both jobs, by including the "ath" claim > in the proof to the AS2 token endpoint and requiring th

Re: [OAUTH-WG] Clarifications regarding aud claim in JWT AT profile

cation be added as a > mandatory aud for the AT (similar to the id_token)? > > Best Regards, > Janak Amarasena > > On Fri, Jul 15, 2022 at 2:54 PM Warren Parad wrote: > >> The aud claim should be the "application" or "resource server" that the >

Re: [OAUTH-WG] Clarifications regarding aud claim in JWT AT profile

The aud claim should be the "application" or "resource server" that the token would be used with, neither the authorization server nor the client that receives the token should be the value. On Fri, Jul 15, 2022 at 7:27 AM Janak Amarasena wrote: > Hi, > > I am sending this email to clarify

Re: [OAUTH-WG] .well-known/jwks.json and constrained-voucher and RFC7517

I don't know if this is relevant, but jwks.json isn't registered, because it doesn't have to be at that location. The /.well-known/openid-configuration discovery document, which is registered, uses the jwks_uri property to specify the location of the jwks. For instance, our product doesn't have

Re: [OAUTH-WG] MITRE Updated Token Chaining Profile for Multi ICAM Ecosystems

It might be interesting to point out that there is actually an OAuth token exchange paradigm that already exists. It could be valuable, if for some reason it doesn't support what you are trying to do, to either piecemeal add RFCs for additional claims or update the RFC to include additional use

Re: [OAUTH-WG] DPoP with token exchange where the subject_token and / or actor_token is also DPoP bound

What's the flow here? Assuming we are talking about RFC 8693, what's the situation where you would need to do a token exchange, and you actually have access to the subject's DPoP key? If you have access to the subject's key, then you are the subject and can request a new token. Or am I missing

Re: [OAUTH-WG] DPoP JWT claims

I think the registration really helps with discovery, especially as an implementer. When you see or observe these claims in a JWT, you can google them potentially returning no results. If you know about the IANA registry you can find them, even if you don't know that the tokens have anything to do

Re: [OAUTH-WG] Multi-Subject JWT draft

oth questions. > > On Tue, Jun 14, 2022 at 2:22 PM Warren Parad wrote: > >> Is it helpful to challenge this implementation? (and is this email thread >> the right place to do it?) >> >> On Tue, Jun 14, 2022 at 5:27 PM Rifaat Shekh-Yusef < >> rifaat.s.i...@gmail.c

Re: [OAUTH-WG] Multi-Subject JWT draft

> > > > > On Tue, Jun 14, 2022 at 11:09 AM Warren Parad wrote: > >> After reading the draft I also have some concerns. This still isn't >> multi-subject, right? As there is only one subject, there just happens to >> be a new claim with additional information in it.

Re: [OAUTH-WG] Multi-Subject JWT draft

After reading the draft I also have some concerns. This still isn't multi-subject, right? As there is only one subject, there just happens to be a new claim with additional information in it. I'm still behind on the justification for creating this, as at first glance, either the user got an access

Re: [OAUTH-WG] Listing OAuth Access Token Metadata

look into OIDC ID token > specification. Does it imply that an ID token should be used as a Personal > Access Token, instead of an OAuth2 access token, or is it proposed to > extract user information? > > Thank You. > Kind Regards, > > Dhaura Pathirana > > On Mon,

Re: [OAUTH-WG] Listing OAuth Access Token Metadata

I'm tempted to say user created PATs are incompatible with OAuth, and OAuth already has a solution which avoids the user having to manually create these sorts of tokens. Is there a reason OAuth wouldn't be able to handle the specific use case. Warren Parad Founder, CTO Secure your user data

Re: [OAUTH-WG] WGLC for DPoP Document

I support publication. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Wed, Mar 30, 2022 at 2:08 PM Torsten Lodderstedt wrote: > I support publication of this specification. > > Am 30.03.2022 u

Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

ink tools like openapi.tools would start to pop up, and places like oauth.net could choose to host this. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Wed, Mar 2, 2022 at 6:11 PM Daniel Fett wrote: &g

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

Is there a reason you wouldn't want to use the access token to access these resources? That seems like it would be the optimal strategy. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Wed, Mar 2, 2022 a

Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

oviders that support OAuth. Being met with a list of hundreds of libraries and packages doesn't make for a good experience, and do those same developers know if they need PKCE, EdDSA signatures, a library that supports mTLS, probably not. - Warren Warren Parad Founder, CTO Secure your user data w

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

This is a great improvement. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Tue, Feb 15, 2022 at 2:37 PM Neil Madden wrote: > Thanks, these changes address my comments. I am happy with the new dra

Re: [OAUTH-WG] DPoP + Token Revocation

I'm a big fan of not arbitrarily adding security to paths that don't require it. The more complicated it is to do what you want without a concrete reason, the more likely there will be an introduced vulnerability. Consistency on adding requirements to endpoints that don't need it also makes them

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

Then perhaps what is in order is to replace 7638, before moving forward with this one, that way we don't end up in state where implementations are based on unnecessary complexity which isn't backwards compatible. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

I also agree that there hasn't been sufficient review of this document to warrant progressing it. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Fri, Feb 4, 2022 at 6:56 PM David Chadwick <

Re: [OAUTH-WG] OAuth 2.1: Missing token?

It may help to specifically clarify which interaction with the AS are we talking about here. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Fri, Feb 4, 2022 at 10:16 AM Johannes Koch wrote:

Re: [OAUTH-WG] Independent Stream publication of draft-santesson-svt and draft-santesson-svt-jws

Can you link them here? Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Sun, Jan 30, 2022 at 9:47 PM RFC ISE (Adrian Farrel) < rfc-...@rfc-editor.org> wrote: > Hi OAuth, > > The authors o

Re: [OAUTH-WG] Token Revocation error codes

interpret all other tokens as justifications for returning a 4XX status code. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Wed, Jan 26, 2022 at 6:44 PM Sergey Ponomarev wrote: > Hi and sorry for raising

Re: [OAUTH-WG] [IANA #1216704] Expert Review for draft-ietf-oauth-iss-auth-resp (oauth-parameters) (2)

da, please complete the registration. - Warren Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Mon, Jan 24, 2022 at 11:09 PM Amanda Baber via RT < drafts-expert-review-comm...@iana.org&g

Re: [OAUTH-WG] Implicit Grant Flow for authentication on both Client UI and Back End by OIDC id_token verification

such as not needing a backend service, requiring the utilization of the nonce, incorrect usage of the *id_token* to name a few. - Warren Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Wed, Jan 19, 2022 at 1

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

the request isn't protected against CSRF, because no valid token is going to be returned anyway. So I don't think there is an issue here, did I get that correct? Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>.

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

I'm not following to be honest. Could you detail concretely what the flow would be that would result in vulnerability? Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Wed, Jan 5, 2022 at 1:41 PM Be

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

still use PKCE and PAR, nor does WebAuthN provide protection from this problem. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Sat, Dec 18, 2021 at 4:11 PM George Fletcher wrote: > Given the attack

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

there for user's protection. Any AS redirecting the user to an invalid redirect url, isn't doing the right thing. But that only solves the illegitimate phishing urls, it doesn't solve the class of problem where a phishing application is legitimately registered. Warren Parad Founder, CTO Secure

Re: [OAUTH-WG] OAuth Redirection Attacks

entication-advanced-social-engineering-attacks.html If we can't protect against these latter ones, I hardly think protecting against the former is useful/interesting/valuable. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://auth

Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

ey can't do anything with it. Removing the need for the AS to care about DPoP in any way is a huge win. I'm sure I missed a critical part of this somewhere, so I would appreciate any insight others have. - Warren Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Imple

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

, there is no reason to signal back to the client nor convey this to the RS. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Sun, Dec 12, 2021 at 2:29 AM Benjamin Kaduk wrote: > > > On Thu, Dec 09, 2021 at 0

  1   2   >