Essentially, the issuer issued disclosures are fully exposed when exchanged via front-channel. Should in those cases encryption be recommended?

[alenhorvat]

          > Essentially, the issuer issued disclosures are fully exposed when exchanged via front-channel. Should in those cases encryption be recommended?

there is already a section on that https://drafts.oauth.net/oauth-selective-disclosure-jwt/draft-ietf-oauth-selective-disclosure-jwt.html#name-confidentiality-during-tran

and this is a separate topic than the original question raised. signing over Disclosures will not solve this.

Originally posted by @Sakurann in https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/291#issuecomment-1591739581

[alenhorvat]

@Sakurann moving this to a separate, but related issue (when it comes to size of the payload).

I fully agree that the signing of disclosures is not solving the problem.

TLS protects confidentiality, but when the payload is exchanged via the URL, TLS won't help since information remains in the browser history. Here the security model relies on the security of the browser. In this case, the payload should be (always) encrypted since we're dealing with personal data.

If the SD-JWT with disclosures are encrypted, is the size optimisation for compact serialised JWS justifiable? (when content is sent directly to the server or fetched from it, size optimisation can be dropped) - for other protocols like NFC/BLE more efficient encodings exist

[mtaimela]

Good points @alenhorvat,

I would like to add that on top of the browser history, there's also browser cache, shoulder surfing and web logs issues. Web logs brings other dimension to the adopters of the technology, as the web logs can possibly be populated with GDPR related data and cause issues for the current operational practices.

[Sakurann]

Transporting SD-JWT is out of scope of this specification - SD-JWT might be transported via the browser, NFC/BLE, or it might not. I don't disagree there are occurrences when TLS might not be enough, for those cases, we have a following sentence:

Implementers MAY define an envelope format (such as described in Section 7 or nesting the SD-JWT as the plaintext payload of a JWE) to encrypt the SD-JWT when transmitted over an insecure channel.

Would it be helpful if we make it a little more clearer how to encrypt SD-JWT using JWE?

[alenhorvat]

Hi @Sakurann.

Short answer: yes; See below if you agree.

To limit the scope of this issue, here we should only address:

When is the encryption is recommended? (e.g., whenever the payload could be cached, like browser URL) - I believe we can reach an agreement wrt this point.

This would require a sentence or two in a sense: When SD-JWT and disclosures contain personal information (this is a tautology) and the information may be cached or otherwise captured (in plain text) during the transmission, the SD-JWT and the disclosures SHOULD be encrypted using JWE. Example: when SD-JWT and disclosures are transmitted via URL, the information may be stored/cached in the browser's history, ...

[bc-pi]

Some additions or clarifications to the section currently called "Confidentiality during Transport" along those lines certainly seem appropriate and useful. A PR with concrete suggested text would be helpful.

[bc-pi]

309 has been merged