entication of the client anybody could push an
> authorization request, and nothing would be gained. Thus, client
> authentication is required.
>
> Best regards,
> Benjamin
> Von: Nikos Fotiou
> Gesendet: Freitag, 29. November 2024 13:11
> An: oauth@ietf.org
>
Hi,
I was wondering why in PAR the client authenticates itself also to the
authorization endpoint
(https://datatracker.ietf.org/doc/html/rfc9126#section-2.1).
Best,
Nikos___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le.
Hi,
I am doing some research about work related to SD-JWT. I found this old
paper, which presents a solution similar to the SD-JWT disclosures
Ron Steinfeld et al. "Content Extraction Signatures", 2001 (
https://eprint.iacr.org/2002/016.pdf)
May be its formalizations and theorems are useful to th
I was wondering if ever occured to use a JSON path-like approach as
disclosure name. This will result in a single top level _sd key and will
remove the need for sperating discolsures that conern objects vs those that
concern arrays. If this has been disussed in the past, what are its
disadvantages?
" familyName":
"9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",
"birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ"
}
}
}
Thanks,
Nikos
-Original Message-
From: Kristina Yasuda
Sent: Wednesday, Ju
Hi,
You are saying "merge payload". But how? In example 4 of section A.3,
"given_name", "family_name", "birthdate" must be moved inside the "vc" claim to
produce a valid payload. But nothing indicates that.
Best,
Nikos
--
Nikos Fotiou - h
information required to validate a proof is in the signature. I believe this is
a cleaner approach since you can re-use existing infrastructure simply by
adding support for a new signature type.
Best,
Nikos
From: Daniel Fett
Sent: Tuesday, June 28, 2022 1:17 PM
To: Nikos Fotiou ; oauth
sd_digests":["sub", "given_name", "family_name", "email", "phone_number",
"address", "birthdate"]
}
Best,
Nikos
From: OAuth On Behalf Of Daniel Fett
Sent: Tuesday, June 28, 2022 10:30 AM
To: oauth@ietf.org
Subje
it necessary to
nest them under the sd_digests claim?
Also a small detail: if you decode the token at the end of section 5.2, instead
of "sd_digests" it uses "_sd"
Best,
Nikos
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
ion to the access token) is a
valid strategy. This way clients would have to share their "client secret" in
addition to the access token. Would that work?
Best,
Nikos
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Ec
Vladimir
>
> Vladimir Dzhuvinov
> On 11/12/2021 12:35, Nikos Fotiou wrote:
>> Hi,
>>
>> I have a use case where a resource server is protected and can only be
>> accessed if a JWT is presented. Is there any way for the server to
>> "indicate"
lated into "I expect tokens form iss
X with claims [A,B,C]"
Best,
Nikos
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr
smime.p7s
Description:
")?
Best,
Nikos
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr
smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
ion. So we do not use Verifiable Presentations at all.
Best,
Nikos
> On Sep 30, 2021, at 12:47 AM, Nikos Fotiou wrote:
>
> FYI, this is exactly what we are doing in [1] to manage Verifiable
Credentials using OAuth2.0. The AS issues a verifiable credential that stays
(for long time) in the client.
rks (ICCCN),
Athens, Greece, July 2021
(https://mm.aueb.gr/publications/0a8b37c5-c814-4056-88a7-19556221728c.pdf)
[2]https://essif-lab.eu
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr
> O
Hi,
For a research project we have implemented key rotation by leveraging “Token
Introspection” (see section 6.2 here
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-6.2 ) Of
course the drawback of this approach is that the authorization server must
always know the curre
s encoded. So may be it is more appropriate to say "the JOSE
header" instead of "the header of the JWT".
Best,
Nikos
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https
?
Thanks a lot,
Nikos
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr
smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing
Hi,
The token is granted to a client based on the authorization grant and not the
client's key. Therefore, a client may use a different key per token. At least
this is an approach we are following.
Best,
Nikos
-Original Message-
From: OAuth On Behalf Of Justin Richer
Sent: Friday, Nov
Hi all,
There was some discussion about adding “server contribution” in the DPoP proof.
I was wondering if the “challenge” server response described in section 6 can
include such a contribution (e.g., a server generated nonce).
Best,
Nikos
From: OAuth On Behalf Of Brian Campbell
Sent:
proprietary JWT
access tokens layout”, I feel it is restrictive.
Best,
Nikos
From: Vittorio Bertocci
Sent: Tuesday, March 24, 2020 7:57 PM
To: Nikos Fotiou
Cc: Hannes Tschofenig ; oauth
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens"
Hi all,
Allow me some comments and forgive me if some of them are naïve.
- In Section 2.2 why nbf claim
(https://tools.ietf.org/html/rfc7519#section-4.1.5) is not considered? I can
imagine some interesting applications of this claim.
- In the same section, it is not clear why some claims are
22 matches
Mail list logo
