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 email archives across two groups, I speculate that this is because JWTs are at a different layer than JOSE - the JOSE specifications defined algorithms and serializations for cryptographic messages, while JWT defined (generalized) application-layer semantics. JWS and JWE allows for arbitrary binary payloads, while JWT mandates a specific document format - a JSON object of higher-layer security and subject claims. Likewise, other groups and individuals outside of OAUTH have further defined how to process JWTs for their own specific application space, just like OAUTH produced a specification recommending how to use JWTs for access tokens. To have SD-JWT under the JOSE group (or another JWP group) would mean that it was chartered to define such application-layer semantics, in addition to the lower layer work of specifying algorithms and serialization of cryptographic data. SD-JWT is an incremental addition on top of JWTs; while it does need a new compact representation to express additional information, the idea is that it can be implemented as incremental logic on top of existing JWT processing libraries. This is core to the current design, and why there are already multiple implementations of the draft. JWP does envision a different approach from SD-JWT, where you have the concept of multiple (potentially binary) payloads as part of the core data model and serializations. A JWT/SD-JWT equivalent (such as JPTs - https://www.ietf.org/id/draft-jmiller-jose-json-proof-token-00.html ) would define how claims are mapped to particular payloads in a JWP. To avoid going too deeply into my own biases here, I think the approach defined by JWP has many benefits. However, that work is just beginning. Similar to how the work on TLS 1.3 didn’t stop people from specifying new capabilities for TLS 1.2, I don’t think the eventual goals of JWP+JPT should detract from specifying SD-JWT. -DW > On Aug 5, 2022, at 3:28 AM, Warren Parad <[email protected]> > wrote: > > 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 > <[email protected] <mailto:[email protected]>> > 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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
