Mandate JAR-encoded Request Objects

[paulbastian]

It should be discussed to mandate the JAR-encoded Authorization Request according to RFC9101 and restrict usage of URL- encoded Authorization Request from RFC6749 as

1. they do not offer integrity
2. they do not offer authenticity

Restricting the URL-encoded pattern could result in a significant security improvement.

[yaron-zehavi]

+1 signed requests obviously offer improved security. I think the reasons why not to force usage of JAR is to ensure interoperability across (older) implementations of OAuth 2.0.

OIDC4VP Overview says: "Any of the OAuth 2.0 related specifications (...) and Best Current Practice (BCP) documents (...) can be implemented on top of this specification."

Even the [BCP|https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics] doesn't mandate the use of JAR, so I guess if OIDC4VP will mandate it, it will violate it's declared intent to support ANY of the OAuth 2.0 related specs.

I for one support compromising interoperability to achieve better security, OR offering a way for parties (wallets, end-users, etc) to be made aware of the methods used and reject insecure requests (like browsers warn users against broken TLS)

[Sakurann]

profiles of OpenID4VP might be a better place to mandate JAR...

[babisRoutis]

For what is worth, I think that making JAR mandatory, in addition to the improvements on integrity and authenticity, will make the VP spec and the wallet implementations simpler.

For example, client_id_scheme redirect_uri probably wouldn't make sense because it can only be used with non-JAR request.

[awoie]

For what is worth, I think that making JAR mandatory, in addition to the improvements on integrity and authenticity, will make the VP spec and the wallet implementations simpler.

For example, client_id_scheme redirect_uri probably wouldn't make sense because it can only be used with non-JAR request.

If it is signed and mandatory, then we need a simple client_id_scheme that can work for most RPs, e.g., something based on well-known as proposed here #103 .

[babisRoutis]

For what is worth, I think that making JAR mandatory, in addition to the improvements on integrity and authenticity, will make the VP spec and the wallet implementations simpler. For example, client_id_scheme redirect_uri probably wouldn't make sense because it can only be used with non-JAR request.

If it is signed and mandatory, then we need a simple client_id_scheme that can work for most RPs, e.g., something based on well-known as proposed here #103 .

Agree on that. Have though a question about this : https://github.com/openid/OpenID4VP/issues/82#issuecomment-2014692823

[jogu]

For what is worth, I think that making JAR mandatory, in addition to the improvements on integrity and authenticity, will make the VP spec and the wallet implementations simpler.

The VP spec is striving to be fairly generic and cater for many use cases, I'm not sure if we could achieve a consensus on making JAR mandatory.

For higher security and interoperability we are defining a profile here: https://github.com/openid/oid4vc-haip-sd-jwt-vc (which does mandate JAR)

[babisRoutis]

For what is worth, I think that making JAR mandatory, in addition to the improvements on integrity and authenticity, will make the VP spec and the wallet implementations simpler.

The VP spec is striving to be fairly generic and cater for many use cases, I'm not sure if we could achieve a consensus on making JAR mandatory.

For higher security and interoperability we are defining a profile here: https://github.com/openid/oid4vc-haip-sd-jwt-vc (which does mandate JAR)

@jogu I have a slightly different view on this :smile:

Indeed, there are profiles such as HAIP, ISO-23220-4, ISO-18013-7 and who knows what will come next. Each of these profiles focuses on a specific format. HAIP in sd-jwt-vc, and ISO to mso_mdoc. Certainly they share several common choices (for instance supported client_id_scheme, JAR, and if I remember correctly JARM, etc) but being independently defined this could be just a coincidence.

From a Verifier & Wallet perspective it would have been simpler to confine the profile choices (by making JAR mandatory), I think.

I do get the point of VP being generic and inclusive but I think that it is more important to lower the complexity of implementing VP to increase adoption.

[c2bo]

I would not mandate the Request Object to be signed in the "generic" OpenID4VP spec, but I do see that there might be value in switching to pure JAR instead of the mixed mode right now (and allowing unsigned request objects with alg=none).

[paulbastian]

My fear is that if the specification becomes too broad, it will lessen the interoperability between the profiles.

[jogu]

I think we should avoid alg=none wherever possible given it's history of security issues.

[Sakurann]

My fear is that if the specification becomes too broad, it will lessen the interoperability between the profiles.

I don't understand that. Different profiles have zero mandate to interoperate among themselves.

[jogu]

I don't think we need to mandate JAR everywhere as we appear to have determined that in some cases unsigned requests are sufficiently secure when done over the Browser API.

I'm not sure I'm seeing any consensus on something that could be done.

I think the practical way forward might be to add a section to security considerations pointing out that unsigned non-browser API requests might be problematic. Does anyone support/object to that or have other suggestions on other ways forward that might achieve consensus?

[Sakurann]

I don't think we need to mandate JAR everywhere as we appear to have determined that in some cases unsigned requests are sufficiently secure when done over the Browser API.

+1

security considerations pointing out that unsigned non-browser API requests might be problematic

yes, we can do this, though I would be careful with the language.

not relevant anymore, but...

I think we should avoid alg=none wherever possible given it's history of security issues.

alg=none in JWS is most likely a different layer/context from signed/unsigned request here