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 adoption is t
erver.
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 sec
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
erns that 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
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 following is
an 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
eting and can request 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
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
ned to conduct an 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
USPFO_Ecosystem>
.
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>
___
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
xposing data to a
> malicious attacker is always 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
ways by which 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 pub
il 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
expectations to OPTIONAL, in my opinion would be a
>> 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 t
sed claims, parameters and headers should
be made 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
culated risk exceeds the 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
at authorization 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 pr
o, 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
resource
servers as it depends upon introspection 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
zation 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 Ka
cates in TLS based authentication
mechanism? Section 2 of RFC 7517 states:
> 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
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 based
ng 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
e maturity 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
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
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
on 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
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
