Re: [OAUTH-WG] DPoP and Dynamic Client Registration

[Denis]

Hi George,

Is is unclear whether you are considering the OAuth 2.X Framework
or the three roles model (i.e., with the Holder, the Issuer and the 
Verifier).


Denis


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 registration 
endpoint?


I'm aware of the client attestation work but that isn't quite the same 
thing.


Thoughts?

Thanks,
George



The information contained in this e-mail may be confidential and/or 
proprietary to Capital One and/or its affiliates and may only be used 
solely in performance of work or services for Capital One. The 
information transmitted herewith is intended only for use by the 
individual or entity to which it is addressed. If the reader of this 
message is not the intended recipient, you are hereby notified that 
any review, retransmission, dissemination, distribution, copying or 
other use of, or taking of any action in reliance upon this 
information is strictly prohibited. If you have received this 
communication in error, please contact the sender and delete the 
material from your computer.




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[David Waite]

I support adoption

-DW

> On Nov 14, 2023, at 4:59 AM, Rifaat Shekh-Yusef  
> wrote:
> 
> 
> All,
> 
> This is an official call for adoption for the Identity Chaining draft:
> https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/
> 
> Please, reply on the mailing list and let us know if you are in favor or 
> against adopting this draft as WG document, by Nov 28th.
> 
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Kelley Burgin]

I support adoption

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Kelley Burgin]

I support adoption

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Parameter pollution with redirect_uri injection in Authorization step

[Michael Jones]

An issue was filed in the OpenID Connect repository at 
https://bitbucket.org/openid/connect/issues/2074/parameter-pollution-with-redirect_uri
 that the working group believes is actually about OAuth and not specific to 
OpenID Connect.  The description of the issue is:


We have researched the OAuth protocol and identified a new class of attack OPP 
derived from the pollution of the redirect_uri in the Authorization request, 
which affected 10/16 popular IDPs.
PAPER

Including an attacker code as a parameter of the redirect_uri in the 
Authorization request generates an Authorization response containing double 
code parameters. This can cause a loginCSRF attack on the Client site.

We would like to see the specification to include a check over the redirect_uri 
parameters in the Authorization request.
For example, an explicit directive to refuse requests containing a redirect_uri 
with a code parameter in the Authorization request.

I'm curious to hear people's analysis of this and whether, for instance, 
there's guidance that we should add to the OAuth Security BCP.

   -- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Michael Jenkins]

I support adoption.

On Wed, Nov 15, 2023 at 3:10 PM Brian Campbell  wrote:

> I support adoption.
>
> On Tue, Nov 14, 2023 at 5:59 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> All,
>>
>> This is an *official* call for adoption for the *Identity Chaining *
>> draft:
>>
>> https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/
>>
>> Please, reply on the mailing list and let us know if you are in favor or
>> against adopting this draft as WG document, by *Nov 28th.*
>>
>> Regards,
>>  Rifaat & Hannes
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Mike Jenkins
mjje...@cyber.nsa.gov 
443-598-7837
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] DPoP and Dynamic Client Registration

[George Fletcher]

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 registration endpoint?

I'm aware of the client attestation work but that isn't quite the same
thing.

Thoughts?

Thanks,
George

__



The information contained in this e-mail may be confidential and/or proprietary 
to Capital One and/or its affiliates and may only be used solely in performance 
of work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth