Hi Dick,
My previous emails do not even obliquely refer to security by obscurity. It
is about design patterns and excessive information disclosure.
Regards
Jaimandeep Singh
On Sat, 26 Aug, 2023, 8:27 pm Dick Hardt, wrote:
> Jaimandeep: Do I understand your objection to adopt
.
Thanks
Jaimandeep Singh
On Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki wrote:
> Hi Jaimandeep,
>
> As with many OAuth extensions, this is not obligatory to implement unless
> you need the functionality it provides. Many of the concerns you mention
> are referenced in the security
is disclosed.
Thanks
Jaimandeep Singh
On Thu, Aug 24, 2023 at 12:32 AM 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/
>
> Please, repl
+ PKCE + DPoP -
basic auth
Regards
Jaimandeep Singh
On Sun, Jul 30, 2023 at 7:44 PM Pieter Kasselman wrote:
> I support adoption.
>
>
>
> *From:* OAuth *On Behalf Of *Rifaat Shekh-Yusef
> *Sent:* Saturday, July 29, 2023 8:27 PM
> *To:* oauth
> *Subject:* [OAUTH-WG] Call fo
at we can look at to address the
concerns in terms of performance penalty?
(b) Is there a need to provide clear guidelines on how to restore the
previous state of the client application to ensure a seamless user
experience in upcoming RFCs?
Regards
Jaimandeep Singh
On Thu, Mar 16, 2023 at 5:39 PM Ri
can be added to discuss the
use of the "state" parameter design pattern for preserving the current
state and the impact it may have on performance of the oauth.
Regards
Jaimandeep Singh
On Wed, 15 Mar, 2023, 7:34 pm Rifaat Shekh-Yusef,
wrote:
> All,
>
> The foll
be well supported by other mechanisms such as
enabling CORS at proxy level if required by the oauth service providers.
Regards
Jaimandeep Singh
On Thu, Mar 9, 2023 at 9:22 PM Jim Manico wrote:
> > We can either expand on that nuance, or more simply switch the SHOULD
> to MAY so that
equest a time slot from Rifaat.
Regards
Jaimandeep Singh
On Tue, 7 Mar, 2023, 8:30 pm Karsten Meyer zu Selhausen, <
karsten.meyerzuselhau...@hackmanit.de> wrote:
> The benefit of not storing the state of all users on the server-side is
> still present. The client only needs to store and use
blication/367557833_Unified_Singular_Protocol_Flow_for_OAuth_USPFO_Ecosystem>
.
These can be considered for discussion in the upcoming IETF.
Regards
Jaimandeep Singh
On Tue, Mar 7, 2023 at 4:04 AM Yannick Majoros wrote:
> Hi Rodrigo,
>
> Thanks for the link. I'm already familiar with that document, but maybe
> you can poin
integrity check and
prevent client impersonation than relying solely on basic authentication,
which is prone to leakages of client_secret.
Kind Regards
Jaimandeep Singh
On Fri, Feb 24, 2023 at 3:37 PM Oliva Fernandez, Jorge
wrote:
> Hi Jaimandeep,
>
>
>
> I have read the paper and have some
.
I'm eager to hear your thoughts and feedback. Please feel free to drop me a
message at with your valuable insights.
--
Regards and Best Wishes
Jaimandeep Singh
LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
___
OAuth mailin
ith the standard "authorization request" which may not include the acr
values.
Regards
Jaimandeep Singh
On Fri, 4 Nov, 2022, 12:27 pm Vittorio Bertocci, wrote:
>
> "By reference": :)
>
> 1) There are two differences between acr_values and requesting acr as an
>
th
> some valuable responses. I do not see a need for any further discussion at
> this stage.
>
> The next step is the shepherd review, which could start a new discussion
> about this document.
>
> Regards,
> Rifaat
>
>
> On Tue, Oct 25, 2022 at 2:11 PM Jaimandeep Singh 4
s a concern, this is opt-in functionality by the
> RS, so if they are concerned they need not implement the RFC. I'd ask for
> at least one practical attack that this RFC enables (not necessarily
> causes).
>
> On Tue, Oct 25, 2022 at 1:29 PM Jaimandeep Singh <
> jaimandeep.phd
hich the RS
returns a signed JWT token containing "acr_values" or other such parameters
which are opaque to the client applications. I also appreciate that signed
JWT will create its own complexities especially with regards to verifying
the association between the RS and its public key.
s email I'm now lost on the current issues with the spec
> from your perspective which makes it hard, at least for me, to continue
> this conversation.
>
> Is item 1 the primary concern you want to discuss or is it something else?
>
> On Mon, Oct 24, 2022, 07:52 Jaimandeep Singh <
mistake. We aren't leaving others as "non-compliant". Sure they are
>> "non-compliant" with this new RFC, but they aren't "non-compliant" with
>> regards to OIDC nor OAuth2.0.
>>
>> On the flip side, I'm not sure how I feel about directly referencing the
>&g
ade OPTIONAL.
*Item No 4*: How much “Freshness” is fresh?
*Follow-on Comment*: The *term* "freshness" may have earlier precedent but
the context is different.
*Recommendation*. Let's not use a term which cannot be quantified and is
open to different interpretations by readers/implementers.
Ki
allowed risk.
>
> On Sat, Oct 15, 2022 at 10:58 PM Jaimandeep Singh 40nfsu.ac...@dmarc.ietf.org> wrote:
>
>> Dear Brian,
>>
>> I strongly support this work. I have recently written a conference paper
>> on supporting similar ideas titled '*Resilient Risk based A
zation server end while issuing new
access when the older ones expire. This can avoid forcing the complete
authentication cycle at client end.
Regards
Jaimandeep Singh
On Wed, Oct 12, 2022 at 3:25 AM Brian Campbell wrote:
> I don't know offhand a better place or if your specific privacy
> c
orld.
Also, it will give a definite time period after which the consent
automatically expires. It will also improve the overall security of the
protocol.
Kind Regards
Jaimandeep Singh
On Wed, Aug 24, 2022 at 8:23 PM Torsten Lodderstedt wrote:
> Hi,
>
> the consent is not bound to the cod
ospection metadata received from the
authorization server.
Regards and Best Wishes
Jaimandeep singh
On Thu, Aug 18, 2022 at 4:16 PM Takahiko Kawasaki wrote:
> Dear Jaimandeep,
>
> Regarding the first question.
>
> If the token endpoint of an authorization server and protected
n code temporary
especially when used with DPoP and thumbprint cnf. This will reduce the
headache of asking the consent from a human user because the refresh token
expired.
For kind consideration of the members please.
Regards and Best Wishes
Jaimandeep Singh
On Fri, Aug 19, 2022 at 7:07 PM Karsten
t; For instance, these keys might be used by some applications for validating
> signed requests made to the token endpoint when using JWTs for client
> authentication
3. It will be great if someone can help with clarity on the above aspects.
Regards and Best Wi
Congratulations to the SD-JWT team and all the members for the hard work
and patiently addressing all the concerns.
Regards and Best Wishes
Jaimandeep Singh
On Fri, 12 Aug, 2022, 5:51 pm Rifaat Shekh-Yusef,
wrote:
> Based on the feedback during the IETF meeting in Philadelphia and ba
support issuing refresh tokens by AS in the first place. I
think there is a need to deliberate on this issue in the next update /
errata for RFC 8705.
Regards and Best Wishes
Jaimandeep Singh
On Thu, Aug 11, 2022 at 11:46 PM wrote:
> Hi Brian,
>
> Thanks for the prompt response. We will w
on how things
are going forward.
Regards and Best Wishes
Jaimandeep Singh
On Thu, Aug 4, 2022 at 9:17 PM David Chadwick <
d.w.chadw...@verifiablecredentials.info> wrote:
> Answers inline below
> On 03/08/2022 14:57, Torsten Lodderstedt wrote:
>
>
> Am 02.08.2022 um 19:30 s
of problems. They are
actively seeking participation in the area of SD-JWT.
5. In view of above I am presently not in favour of its adoption in
WG-OAUTH.
Regards
Jaimandeep Singh
On Fri, Jul 29, 2022 at 6:43 AM Brian Campbell wrote:
> I support adoption.
>
> On Thu, Jul 28, 2022, 8:17
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 here. That way we aren't
>> opening old conversations in the middle of the meeting, and also it lets us
>> be prepared to understand the
he opinion that an important parameter like
"redirect_uri" needs to be more clearly defined. It can either be OPTIONAL
or REQUIRED, but definitely cannot be both (as in the present
definition). Maybe Aaron can bring up the topic again for discussion in the
side meeting for further deliberations.
Rega
of DPoP.
*Option II:*
5. In the main meeting we discussed the possibility of moving towards a
uniform OAuth flow by converting public apps to confidential apps. We need
more discussions on the same.
Regards and Best Wishes
Jaimandeep Singh
___
OAuth mailing
31 matches
Mail list logo
