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 public key in the sub_jwk claim, or what a "reference" to the public key actually means. Is the server an AS as in OAuth?, or are we building on top of another token creation standard? If it is OAuth, It isn't clear if we need a new indicator in the token response that tells us that the salt container is attached to the token and that it shouldn't blindly be passed along. It isn't clear from this discussion if we need token revocation. Assuming it is the OAuth token exchange that we are building on top of, there are lots of open questions of interoperability. I.e. Does the digest go in the access token? If it isn't OAuth, we don't have any guide on how to actually do the token generation, how to verify the signature of the token with the digest, and I'm sure there are more things. We don't need to have both in the same WG, that wasn't my point, the point is if there is a concrete reason that others aren't working on it, I wanted to know why. There are JWPs, I don't know anything about them, but it doesn't really matter if they have different approaches, different cryptos, etc... Let's look at the features, that's at the core of what matters. So far the only feature we've been able to nail down is *offline claim transmission*. Will JWPs support *offline claim transmission*? On Fri, Aug 5, 2022 at 11:55 AM Daniel Fett <mail= 40danielfett...@dmarc.ietf.org> wrote: > 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 nonetheless good reasons to have SD-JWT. Having SD-JWT in OAuth WG is > not an attempt to "backdoor" anything in! > > I also didn't say that we should adopt SD-JWT because it has been > implemented. You took my statement out of context. I wanted to underline > that the spec is practically feature-complete and can be implemented today, > providing the features promised. Meanwhile, JWP is not there yet. > > But, SD-JWT is not in production yet. If the OAuth WG decides that > substantial changes are required, now is the best time for that. > > Also, I wanted to highlight with my statement that SD-JWT is easy to > implement due to its simplicity. > > -Daniel > > Am 5. August 2022 11:28:49 MESZ schrieb Warren Parad <wparad= > 40rhosys...@dmarc.ietf.org>: >> >> 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 seems like the appropriate >> one, thinks it wouldn't make sense. If it is just a matter of timing, then >> whatever. But if there are concrete recommendations from that group, I >> would love to hear them. >> >> On Fri, Aug 5, 2022 at 10:26 AM Daniel Fett <fett= >> 40danielfett...@dmarc.ietf.org> wrote: >> >>> 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. >>> >>> -Daniel >>> >>> _______________________________________________ >>> 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
