5 ms·

JSON Web Proofs

51 points by tentacleuno 3y ago

therein 3y ago
JWT, JWS, JWE, JWP. This is getting confusing. I am still unsure if JWT can be encrypted. You find libraries encrypting it but then does it become JWE? Is it the same thing if the library still calls it a JWT? Are all of these just subtypes of JWTs or standalone RFCs? It is all over the place. Makes me just take the route of creating a custom JSON payload and then encrypting or signing it.
- erikaww 3y ago
  https://xkcd.com/927/ https://xkcd.com/927/
  - deleted 3y ago
    [deleted]
  - uxp8u61q 3y ago
    That's not relevant. All the things in question are answers to different problems. They're not different approaches to the same problem.
- dwaite 3y ago
  Yes, encrypted JWTs are a thing. You typically have a JWT as a signed payload, then encrypt that JWT using JWE. An example of such an approach is in the RFC appendix: https://datatracker.ietf.org/doc/html/rfc7519#appendix-A.2 https://datatracker.ietf.org/doc/html/rfc7519#appendix-A.2 Perhaps the biggest misconception about JOSE specs and JWT is that they are components, not a “batteries included” format. They are meant to be used to define further applications, such as ACMEv2. Libraries often are written to solve specific problems (say, validating an OpenID Connect id_token) and blur the decisions such specifications made in profiling for their own use. The nesting approach provides for non-repudiation of the decrypted JWT, which is important for federated identity use cases.
- gregmac 3y ago
  Agree the naming is a bit confusing. They're all types of JSON Web Tokens (JWT), though. They're also defined in separate RFCs, but reference back to the JWT one. They're all made of base64url-encodes segments, separated by a period. The first segment is always the header, and you can easily identify them by starting with "eyJh". A plain JWT has two segments, the second is the payload. In practice AFAIK it's not really used because it's just bloating your data. JWS has a third segment that's the signature of the payload plus private key, and can be verified if you have the public key. JWT.io is a site where you can play with these. JWE has five segments including an encrypted symmetric key, the IV and ciphertext. So yeah, JWE is technically a different subtype. I'll only note you can stick an already-encrypted payload in a plain JWT or a JWS, and you can also take a JWT or JWS and encrypt it, and none of these is the same as actual JWE token.
- miunau 3y ago
  Might I suggest Paseto (https://paseto.io/ https://paseto.io/) instead of writing it yourself - it solves a lot of the headaches of JWT. Signing and encryption are two different things that require two different sets of keys, so you can't mess it up. (Full disclosure, I've written one implementation: https://github.com/auth70/paseto-ts https://github.com/auth70/paseto-ts)
  - Zamicol 3y ago
    And shameless plug for another alternative, Coze: https://github.com/Cyphrme/Coze https://github.com/Cyphrme/Coze
dwaite 3y ago
Hello! I a one of the editors, feel free to ask questions.
- 8n4vidtmkvmk 3y ago
  What are some use cases for these?
  - dwaite 3y ago
    You can say JWS (JSON Web Signature) provides integrity/authentication and JWE (JSON Web Encryption) provides confidentiality. JWP (JSON Web Proofs) are meant to provide for privacy. I'll give an example of digital documents used as credentials. Imaging a health record containing your vaccination history. This could be signed and shared as an interchange record between doctors. It could also be used as a proof of vaccination - this is what SMART Health Cards were. However, there is considerable information in those records that I may not want to share - not just that I _was_ vaccinated for instance, but when and where, by whom, from which batch, potentially under what insurance. It is also common to have personal information like full name and potentially home address. So you may want the ability to select which information is disclosed - you can do this with traditional signature and hashing algorithms by building a Merkle tree or nesting signatures with ephemeral keys. The document still has integrity, but only some subset of the information has been shared. The signatures and hashes from a classic algorithm serve as potentially trackable identifiers as well. Newer algorithms like BBS provide unlinkability, where presentation of the same source document multiple times does not allow for parties to correlate my usages. Finally, you also may want to disclose derived information - such as just that I have a vaccination in the last x months, rather than the precise date or location, or just that I'm of legal age to purchase alcohol in my country, rather than my birthdate. These sorts of predicate proofs are also of interest to the group, although the algorithms and representations aren't as far along yet.
    - erhaetherth 3y ago
      > Finally, you also may want to disclose derived information - such as just that I have a vaccination in the last x months, rather than the precise date or location, or just that I'm of legal age to purchase alcohol in my country, rather than my birthdate. These sorts of predicate proofs are also of interest to the group, although the algorithms and representations aren't as far along yet. That sounds kind of crazy. I can't imagine how you'd prove derived data. Very cool though. Thanks!
adamddev1 3y ago
I clicked on this thinking it might me something like Agda for web development.
denys_potapov 3y ago
eyJ... — is a beginning of base64 encoded JSON. The fact that I know it, and see it in standards make me feel bad. I can't proof that this is wrong, but encoding one text format in other text format and wrapping it in third text format — seems wasteful and hacky. This relates not only to this specs, but rather to web development in general.
- shp0ngle 3y ago
  eyJhbG
- Retr0id 3y ago
  base64 is not just a text format, but one that's safely transmissible through e.g. 7-bit only mediums, or being embedded into a URL (assuming url-safe b64!), being stored in a cookie and passed through janky middlewares, etc. etc. Further, base64 doesn't actually encode strings, it encodes bytes. If you're doing cryptography on something, you want to have a canonical byte representation. Canonicalizing JSON itself is error-prone, whereas decoding b64 gives you the same bytes every time.
  - Zamicol 3y ago
    Sanitized, well formed JSON is generally not horribly URL encoded. It's typically less overhead than base64. Also, for well formed JSON (not arbitrary JSON), it also works fine in HTTP headers. I think those two situations cover about 90% of use cases. For example, here is a JSON payload URL encoded. It's not too bad, and much better than base64: https://cyphr.me/coze#?input={%22pay%22:{%22msg%22:%22Hello%20Retr0id!%22,%22alg%22:%22ES256%22,%22iat%22:1701603747,%22tmb%22:%221KGZzsqiFAYE5uDO3CCh3PMl9pqwlG1RrI8i5gZY94c%22,%22typ%22:%22cyphr.me/msg/create%22},%22sig%22:%22vZEALUQShRlLYyhJoGmkxpQhhEeUPlzbIZqyTsUyPBMlJMIqGClgSs3uXTDiwumsMivFQKU8K4z4Ec7WlxYIew%22}&dontSignRevoke&updateIat&selectedAlg=ES256&verify https://cyphr.me/coze#?input={%22pay%22:{%22msg%22:%22Hello%... The initial payload is 238 bytes, URL encoded that payload is 288 bytes, as base 64 it is 318 bytes. (Here's another tool just for that: https://convert.zamicol.com/#?inAlph=text&in=%257B%2522pay%2522%253A%257B%2522msg%2522%253A%2522Hello%2520Retr0id!%2522%252C%2522alg%2522%253A%2522ES256%2522%252C%2522iat%2522%253A1701603747%252C%2522tmb%2522%253A%25221KGZzsqiFAYE5uDO3CCh3PMl9pqwlG1RrI8i5gZY94c%2522%252C%2522typ%2522%253A%2522cyphr.me%252Fmsg%252Fcreate%2522%257D%252C%2522sig%2522%253A%2522vZEALUQShRlLYyhJoGmkxpQhhEeUPlzbIZqyTsUyPBMlJMIqGClgSs3uXTDiwumsMivFQKU8K4z4Ec7WlxYIew%2522%257D&outAlph=b64ut https://convert.zamicol.com/#?inAlph=text&in=%257B%2522pay%2...)
deleted 3y ago
[deleted]
wyc 3y ago
I'm excited to watch this work evolve. It aims to create the envelopes necessary to support new trust systems like those based on zero knowledge proofs on the web for more privacy-preserving claims. What's new about this vs. JWTs? Roughly, JWTs generally happen in two steps: 1. Get JWT (private) 2. Present JWT JWPs can have three: 1. Get JWP precursor (private) 2. Generate JWP from JWP precursor (private) 3. Present JWP Between steps 1 and 2, JWPs can support algorithms that create selective disclosure, proof generation, etc. so you can show you're over 21 without revealing your date of birth. This extra steps means you don't necessarily need to share the original payload you got from an issuer. Another nice aspect is that ZKP-based algorithms can improve unlinkability to make surveillance more difficult.

51 points by tentacleuno 3y ago

JWT, JWS, JWE, JWP. This is getting confusing. I am still unsure if JWT can be encrypted. You find libraries encrypting it but then does it become JWE? Is it the same thing if the library still calls it a JWT? Are all of these just subtypes of JWTs or standalone RFCs? It is all over the place. Makes me just take the route of creating a custom JSON payload and then encrypting or signing it.

erikaww 3y ago
https://xkcd.com/927/ https://xkcd.com/927/
- deleted 3y ago
  [deleted]
- uxp8u61q 3y ago
  That's not relevant. All the things in question are answers to different problems. They're not different approaches to the same problem.
dwaite 3y ago
Yes, encrypted JWTs are a thing. You typically have a JWT as a signed payload, then encrypt that JWT using JWE. An example of such an approach is in the RFC appendix: https://datatracker.ietf.org/doc/html/rfc7519#appendix-A.2 https://datatracker.ietf.org/doc/html/rfc7519#appendix-A.2 Perhaps the biggest misconception about JOSE specs and JWT is that they are components, not a “batteries included” format. They are meant to be used to define further applications, such as ACMEv2. Libraries often are written to solve specific problems (say, validating an OpenID Connect id_token) and blur the decisions such specifications made in profiling for their own use. The nesting approach provides for non-repudiation of the decrypted JWT, which is important for federated identity use cases.
gregmac 3y ago
Agree the naming is a bit confusing. They're all types of JSON Web Tokens (JWT), though. They're also defined in separate RFCs, but reference back to the JWT one. They're all made of base64url-encodes segments, separated by a period. The first segment is always the header, and you can easily identify them by starting with "eyJh". A plain JWT has two segments, the second is the payload. In practice AFAIK it's not really used because it's just bloating your data. JWS has a third segment that's the signature of the payload plus private key, and can be verified if you have the public key. JWT.io is a site where you can play with these. JWE has five segments including an encrypted symmetric key, the IV and ciphertext. So yeah, JWE is technically a different subtype. I'll only note you can stick an already-encrypted payload in a plain JWT or a JWS, and you can also take a JWT or JWS and encrypt it, and none of these is the same as actual JWE token.
miunau 3y ago
Might I suggest Paseto (https://paseto.io/ https://paseto.io/) instead of writing it yourself - it solves a lot of the headaches of JWT. Signing and encryption are two different things that require two different sets of keys, so you can't mess it up. (Full disclosure, I've written one implementation: https://github.com/auth70/paseto-ts https://github.com/auth70/paseto-ts)
- Zamicol 3y ago
  And shameless plug for another alternative, Coze: https://github.com/Cyphrme/Coze https://github.com/Cyphrme/Coze

dwaite 3y ago

Hello! I a one of the editors, feel free to ask questions.

8n4vidtmkvmk 3y ago
What are some use cases for these?
- dwaite 3y ago
  You can say JWS (JSON Web Signature) provides integrity/authentication and JWE (JSON Web Encryption) provides confidentiality. JWP (JSON Web Proofs) are meant to provide for privacy. I'll give an example of digital documents used as credentials. Imaging a health record containing your vaccination history. This could be signed and shared as an interchange record between doctors. It could also be used as a proof of vaccination - this is what SMART Health Cards were. However, there is considerable information in those records that I may not want to share - not just that I _was_ vaccinated for instance, but when and where, by whom, from which batch, potentially under what insurance. It is also common to have personal information like full name and potentially home address. So you may want the ability to select which information is disclosed - you can do this with traditional signature and hashing algorithms by building a Merkle tree or nesting signatures with ephemeral keys. The document still has integrity, but only some subset of the information has been shared. The signatures and hashes from a classic algorithm serve as potentially trackable identifiers as well. Newer algorithms like BBS provide unlinkability, where presentation of the same source document multiple times does not allow for parties to correlate my usages. Finally, you also may want to disclose derived information - such as just that I have a vaccination in the last x months, rather than the precise date or location, or just that I'm of legal age to purchase alcohol in my country, rather than my birthdate. These sorts of predicate proofs are also of interest to the group, although the algorithms and representations aren't as far along yet.
  - erhaetherth 3y ago
    > Finally, you also may want to disclose derived information - such as just that I have a vaccination in the last x months, rather than the precise date or location, or just that I'm of legal age to purchase alcohol in my country, rather than my birthdate. These sorts of predicate proofs are also of interest to the group, although the algorithms and representations aren't as far along yet. That sounds kind of crazy. I can't imagine how you'd prove derived data. Very cool though. Thanks!

adamddev1 3y ago

I clicked on this thinking it might me something like Agda for web development.

denys_potapov 3y ago

eyJ... — is a beginning of base64 encoded JSON. The fact that I know it, and see it in standards make me feel bad. I can't proof that this is wrong, but encoding one text format in other text format and wrapping it in third text format — seems wasteful and hacky. This relates not only to this specs, but rather to web development in general.

shp0ngle 3y ago
eyJhbG
Retr0id 3y ago
base64 is not just a text format, but one that's safely transmissible through e.g. 7-bit only mediums, or being embedded into a URL (assuming url-safe b64!), being stored in a cookie and passed through janky middlewares, etc. etc. Further, base64 doesn't actually encode strings, it encodes bytes. If you're doing cryptography on something, you want to have a canonical byte representation. Canonicalizing JSON itself is error-prone, whereas decoding b64 gives you the same bytes every time.
- Zamicol 3y ago
  Sanitized, well formed JSON is generally not horribly URL encoded. It's typically less overhead than base64. Also, for well formed JSON (not arbitrary JSON), it also works fine in HTTP headers. I think those two situations cover about 90% of use cases. For example, here is a JSON payload URL encoded. It's not too bad, and much better than base64: https://cyphr.me/coze#?input={%22pay%22:{%22msg%22:%22Hello%20Retr0id!%22,%22alg%22:%22ES256%22,%22iat%22:1701603747,%22tmb%22:%221KGZzsqiFAYE5uDO3CCh3PMl9pqwlG1RrI8i5gZY94c%22,%22typ%22:%22cyphr.me/msg/create%22},%22sig%22:%22vZEALUQShRlLYyhJoGmkxpQhhEeUPlzbIZqyTsUyPBMlJMIqGClgSs3uXTDiwumsMivFQKU8K4z4Ec7WlxYIew%22}&dontSignRevoke&updateIat&selectedAlg=ES256&verify https://cyphr.me/coze#?input={%22pay%22:{%22msg%22:%22Hello%... The initial payload is 238 bytes, URL encoded that payload is 288 bytes, as base 64 it is 318 bytes. (Here's another tool just for that: https://convert.zamicol.com/#?inAlph=text&in=%257B%2522pay%2522%253A%257B%2522msg%2522%253A%2522Hello%2520Retr0id!%2522%252C%2522alg%2522%253A%2522ES256%2522%252C%2522iat%2522%253A1701603747%252C%2522tmb%2522%253A%25221KGZzsqiFAYE5uDO3CCh3PMl9pqwlG1RrI8i5gZY94c%2522%252C%2522typ%2522%253A%2522cyphr.me%252Fmsg%252Fcreate%2522%257D%252C%2522sig%2522%253A%2522vZEALUQShRlLYyhJoGmkxpQhhEeUPlzbIZqyTsUyPBMlJMIqGClgSs3uXTDiwumsMivFQKU8K4z4Ec7WlxYIew%2522%257D&outAlph=b64ut https://convert.zamicol.com/#?inAlph=text&in=%257B%2522pay%2...)

deleted 3y ago

[deleted]

wyc 3y ago

I'm excited to watch this work evolve. It aims to create the envelopes necessary to support new trust systems like those based on zero knowledge proofs on the web for more privacy-preserving claims. What's new about this vs. JWTs? Roughly, JWTs generally happen in two steps: 1. Get JWT (private) 2. Present JWT JWPs can have three: 1. Get JWP precursor (private) 2. Generate JWP from JWP precursor (private) 3. Present JWP Between steps 1 and 2, JWPs can support algorithms that create selective disclosure, proof generation, etc. so you can show you're over 21 without revealing your date of birth. This extra steps means you don't necessarily need to share the original payload you got from an issuer. Another nice aspect is that ZKP-based algorithms can improve unlinkability to make surveillance more difficult.