New response mode direct_post.jwt

[Daniel Fett]

If implementers may combine JARM and direct_post, there needs to be a definition of a new response mode direct_post.jwt.

[Kristina Yasuda]

PR #399

also added JARM examples

[Torsten Lodderstedt]

What is the purpose of combining direct post with JARM?

[Daniel Fett]

What is the reason to use JARM in other use cases? (I can guess the answer, but this should probably be spelled out in the text.)

With direct_post, maybe there are use cases where you would want to use encryption to ensure that only a specific receiver can decrypt the response or where a regulation required application-level encryption for some reason.

All I’m saying is that if implementer’s may combine JARM with direct_post, this needs to be defined. Otherwise it should be mentioned as not supported.

[Kristina Yasuda]

I think we should not exclude an option to use JARM with response_mode direct_post. Because some implementers in ISO mDL ecosystem have expressed interest in supporting application level E2E encryption using JARM on top of TLS. It would be limiting having that option only with redirects and not direct_post.

[gffletch]

Any suggestions on how developers find all the different defined response modes and what specs they are defined in?

[Kristina Yasuda]

everything except direct_post.jwt is in JARM spec, which is final, only direct_post.jwt is is openid4vp because that is the only place you will need it.

[Torsten Lodderstedt]

I think we should not exclude an option to use JARM with response_mode direct_post. Because some implementers in ISO mDL ecosystem have expressed interest in supporting application level E2E encryption using JARM on top of TLS. It would be limiting having that option only with redirects and not direct_post.

I understand use of JARM in case of front channel requests, I’m less convinced of JARM in backend, HTTPS protected requests.

If I got your argument right, we would perhaps also need to introduce application level encryption for the token response as well. Is that intended?

[Torsten Lodderstedt]

What is the reason to use JARM in other use cases?

Good question. From the JARM spec: “… it adds support for signing and encryption, sender authentication, audience restriction as well as protection from replay, credential leakage, and mix-up attacks.”

That makes sense for front channel requests because they lack those measures (between verifier and wallet).

direct post is different, as it has most of it at the TLS/HTTPS layer. Sender authentication is the missing piece. I’m not sure JARM is the only/best option for it in the context of direct post.

‌

[Kristina Yasuda]

PR merged