Also, I wanted to take a moment to respond specifically to something in the
shepherd’s review:
> • The DPoP Proof contains a hash of the Access Token, and the Access Token
> contains a hash of the public key in the DPoP Proof. Why do you need both?
> Would one of these be sufficient?
The acce
"the AS can directly issue the restricted token"
-> The use-case is issuance decoupled (ie happens asynchronously) from
presentation, so AS cannot directly issue a restricted token.
"Can you list them out succinctly"
-> For example this thread talked in detail about issuer issuing usbsets of
JWT
So the executive summary is "JWP does solve this problem, but that work
isn't close to being able to provide a solution yet" Or is it something
else?
On Fri, Aug 5, 2022 at 5:22 PM David Waite wrote:
> I can’t speak to what group or charter the JWP work would eventually be
> under, but the JWT s
Can you list them out succinctly, because I don't feel like they have been?
The reason I say that, is if all the entities are online, then the AS can
directly issue the restricted token. So the only argument I can see there
is "We want to reduce the load on AS by delegating some proportion of the
A
I think Brian’s just in Danial about this one, but we’ll let it slide.
And I have in fact gone through and added text about ATH:
https://github.com/danielfett/draft-dpop/pull/168
I opted to add this in the introduction of the section about using access
tokens instead of a separate security cons
I can’t speak to what group or charter the JWP work would eventually be under,
but the JWT specification is one of several examples of a specification that
heavily leveraged the JOSE work but which was started here at OAUTH, outside of
the (at the time active) JOSE WG.
Without perusing old emai
Yes, SD-JWT is not complete and that’s exactly why we are asking for a WG
adoption. The questions you are asking are better answered in the WG,
post-adoption.
Thank you,
Kristina
PS. Offline claim transmission is not the only “feature” of SD-JWT for all of
the reasons that have been previously
It's clear that good thought has been put into the core of it, more so than
other drafts submitted, but not yet feature complete.
For example there is no sense of how the private/public key exchange
actually happens. In *holder binding *scenario, it isn't detailed how to
actually include the publi
It's not that the people I have spoken to didn't like the idea of SD-JWT. It's
just on a different layer than JWPs, using a different approach, different
crypto, providing different features, and on a different timeline. There's no
compelling reason to have both in the same WG. There are nonethe
Maybe they have a good reason for not wanting it, and then we shouldn't be
the WG that backdoor's it in. Also: "other people have already implemented
it" is a cognitive fallacy, so let's not use that as a justification we
have to make the standard.
We should get a concrete reason why a WG that see
Am 05.08.22 um 10:22 schrieb Warren Parad:
> and nobody involved in the JWP effort thinks that SD-JWT should be in that WG
once created
Why?
For the reasons listed, I guess?
Also, mind the "As far as I am aware" part, but I don't remember any
discussions in that direction at IETF114.
-Dan
> and nobody involved in the JWP effort thinks that SD-JWT should be in
that WG once created
Why?
On Fri, Aug 5, 2022, 10:15 Daniel Fett
wrote:
> Hi Jaimandeep,
> Am 04.08.22 um 20:39 schrieb Jaimandeep Singh:
>
> Dear All,
> My compliments to all the collaborators including David for making ef
Hi Jaimandeep,
Am 04.08.22 um 20:39 schrieb Jaimandeep Singh:
Dear All,
My compliments to all the collaborators including David for making
efforts in answering the queries. However, I am of the opinion that we
need to answer some of the more fundamental questions before arriving
at any decisi
13 matches
Mail list logo
