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

Thanks Brian for your response. Do you think DPoP should have an own token type URI registered? https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#uri I did not think about the possibility of having the DPoP proof and the token value put together in the subject/actor_toke

Re: [OAUTH-WG] OAuth WG Agenda @ IETF114

*A reminder *since* this is something new... On Mon, Jul 18, 2022 at 12:44 PM Atul Tulshibagwale wrote: > Hi all, > A reminder this is something new: If you are curious about what the "RPC > Security Standard" item on the agenda is, please review this blog post for > background information: > ht

Re: [OAUTH-WG] OAuth WG Agenda @ IETF114

Hi all, A reminder this is something new: If you are curious about what the "RPC Security Standard" item on the agenda is, please review this blog post for background information: https://sgnl.ai/2022/06/why-we-need-an-rpc-security-standard/ I hope to be able to highlight the issue, and gauge inte

[OAUTH-WG] RAR client metadata

While looking at RAR recently with some prospective implementer, it was noticed that the text around the client metadata is very noncommittal. It says only, "clients announce the authorization details types they use in the new dynamic client registration parameter authorization_details_type" [1] an

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

While there are potentially more tokens involved in a RFC 8693 token exchange, it's still a single client and it's not evident (to me anyway at this point) that there's sufficient need to give it distinct DPoP treatment beyond other token endpoint interaction

Re: [OAUTH-WG] [Technical Errata Reported] RFC9126 (6711)

I believe this should be verified. I'm also the one that reported it though. But it's been sitting in reported status for a while now. On Fri, Oct 15, 2021 at 1:38 PM RFC Errata System wrote: > The following errata report has been submitted for RFC9126, > "OAuth 2.0 Pushed Authorization Requests

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

I find the token exchange RFC to be quite flexible, it allows the subject_token, actor_token and the output token to be of any type, and there is a mechanism to define (register) new urn:ietf:params:oauth:token-type values. The only concrete need is to define a way to pass the accompanying DPoP

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

I agree this is a problem, but as I see it as a problem for Token Exchange, and the lack of flexibility in that standard, it does not make sense to add to the DPoP spec. On Mon, Jul 18, 2022 at 3:33 PM Vladimir Dzhuvinov wrote: > I would like to resurrect this thread and propose a new section to

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

I would like to resurrect this thread and propose a new section to the current DPoP draft which changes nothing in regard to DPoP itself, only adds new parameters to enable DPoP with OAuth 2.0 token exchange (RFC 8693): https://datatracker.ietf.org/doc/html/rfc8693 Why? Token exchange lets a

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

Dear Warren I have resolved my issues thanks for your support. Regards Deepak On Mon, Jul 18, 2022, 14:14 Warren Parad wrote: > no? > > On Mon, Jul 18, 2022 at 10:36 AM Janak Amarasena > wrote: > >> Hi Warren, >> >> Thanks for the input. By client what I meant was the application. If the >

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

no? On Mon, Jul 18, 2022 at 10:36 AM Janak Amarasena wrote: > Hi Warren, > > Thanks for the input. By client what I meant was the application. If the > application can be considered as a valid aud then since the AT is almost > alway received to the application shouldn't the application be added

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

Hi Warren, Thanks for the input. By client what I meant was the application. If the application can be considered as a valid aud then since the AT is almost alway received to the application shouldn't the application be added as a mandatory aud for the AT (similar to the id_token)? Best Regards,