Use expected URL instead of expected origins for IAE flow#695
Use expected URL instead of expected origins for IAE flow#695
Conversation
awoie
requested review from
GarethCOliver,
Sakurann,
c2bo,
jogu,
paulbastian and
tplooker
|
Should this PR also address #698, since it's related to the origin binding? I think the reference in A3.5 won't be correct anymore since it links to "derived Origin (as defined in Section 6.2.1.1)" |
|
This PR needs more reviews. Could you please review again @TimoGlastra |
TimoGlastra
left a comment
TimoGlastra
left a comment
There was a problem hiding this comment.
I think it's missing some required changes to fully remove all references to "Derived origin"
…ion; applied Tim's suggestion
Co-authored-by: Timo Glastra <timo@animo.id>
Co-authored-by: Timo Glastra <timo@animo.id>
There was a problem hiding this comment.
I found the description/terminology a bit confusing: request vs Interactive Authorization Response in our terminology unless i misunderstood something. This is the current text:
The
expected_urlparameter is a non-empty string that contains the endpoint of the Verifier that is returning the request. In theopenid4vp_presentationinteraction type,expected_urlMUST be set to the Interactive Authorization Endpoint.
If
expected_urlis present, the Wallet MUST compare the value in this parameter to the URL of the follow-up request to detect replay of the request from a malicious Verifier.
this is achieved by the Wallet verifying the
expected_urlparameter in the request, which contains the Interactive Authorization Endpoint that initiated the request.
Given the terminology, wouldn't something like this be more fitting?
the
expected_urlparameter is a non-empty string that contains the endpoint of the Authorization Server that is returning the Interactive Authorization Response.
If
expected_urlis present, the Wallet MUST compare the value in this parameter to the URL of the follow-up Interactive Authorization Request to detect replay of the request from a malicious Authorization Server/Verifier.
this is achieved by the Wallet verifying the
expected_urlparameter in the Interactive Authorization Response, which contains the Interactive Authorization Endpoint that initiated the Interactive Authorization Response.
| * The `response_mode` MUST be either `iae_post` for unencrypted responses or `iae_post.jwt` for encrypted responses. These modes are used to indicate to the Wallet to return the response back to the same Interactive Authorization Endpoint. | ||
| * If `expected_origins` is present, it MUST contain only the derived Origin of the Interactive Authorization Endpoint as defined in Section 4 in [@RFC6454]. For example, the derived Origin from `https://example.com/iae` is `https://example.com`. | ||
| * The `expected_origins` parameter MUST NOT be present. | ||
| * When signed requests defined in A.3.2 of [@!OpenID4VP] are used, an addtional `expected_url` parameter MUST be present. The `expected_url` parameter is a non-empty string that contains the endpoint of the Verifier that is returning the request. In the `openid4vp_presentation` interaction type, `expected_url` MUST be set to the Interactive Authorization Endpoint. |
There was a problem hiding this comment.
@c2bo is this better?
| * When signed requests defined in A.3.2 of [@!OpenID4VP] are used, an addtional `expected_url` parameter MUST be present. The `expected_url` parameter is a non-empty string that contains the endpoint of the Verifier that is returning the request. In the `openid4vp_presentation` interaction type, `expected_url` MUST be set to the Interactive Authorization Endpoint. | |
| * When signed requests defined in A.3.2 of [@!OpenID4VP] are used, an additional `expected_url` parameter MUST be present. The `expected_url` parameter is a non-empty string that contains the endpoint of the Authorization Server that is returning the Interactive Authorization Response. In the `openid4vp_presentation` interaction type, `expected_url` MUST be set to the Interactive Authorization Endpoint. |
| When processing the request the following logic applies: | ||
|
|
||
| 1. If `expected_origins` is present, the Wallet MUST ensure that `expected_origins` contains the derived Origin as defined above. | ||
| 1. If `expected_url` is present, the Wallet MUST compare the value in this parameter to the URL of the follow-up request to detect replay of the request from a malicious Verifier. If the URL does not match the value of the `expected_url`, the Wallet MUST return an error. This error SHOULD be an `invalid_request` error. This parameter is not for use in unsigned requests and therefore a Wallet MUST ignore this parameter if it is present in an unsigned request. |
There was a problem hiding this comment.
@c2bo is this better?
| 1. If `expected_url` is present, the Wallet MUST compare the value in this parameter to the URL of the follow-up request to detect replay of the request from a malicious Verifier. If the URL does not match the value of the `expected_url`, the Wallet MUST return an error. This error SHOULD be an `invalid_request` error. This parameter is not for use in unsigned requests and therefore a Wallet MUST ignore this parameter if it is present in an unsigned request. | |
| 1. If `expected_url` is present, the Wallet MUST compare the value in this parameter to the URL of the follow-up Interactive Authorization Request to detect replay of the request from a malicious Authorization Server/Verifier. If the URL does not match the value of the `expected_url`, the Wallet MUST return an error. This error SHOULD be an `invalid_request` error. This parameter is not for use in unsigned requests and therefore a Wallet MUST ignore this parameter if it is present in an unsigned request. |
| Custom extensions ((#iae-custom-extensions)) MUST ensure that this attack is prevented by ensuring one or both of the following: | ||
|
|
||
| 1. The Wallet is able to detect that a request is not presented by the party that initiated the Interactive Authorization Request. In the case of the (#iae-require-presentation) interaction with a signed Presentation request, this is achieved by the Wallet verifying the `expected_origins` parameter in the request, which contains the derived Origin of the Interactive Authorization Endpoint that initiated the request. | ||
| 1. The Wallet is able to detect that a request is not presented by the party that initiated the Interactive Authorization Request. In the case of the (#iae-require-presentation) interaction with a signed Presentation request, this is achieved by the Wallet verifying the `expected_url` parameter in the request, which contains the Interactive Authorization Endpoint that initiated the request. |
There was a problem hiding this comment.
@c2bo is this better?
| 1. The Wallet is able to detect that a request is not presented by the party that initiated the Interactive Authorization Request. In the case of the (#iae-require-presentation) interaction with a signed Presentation request, this is achieved by the Wallet verifying the `expected_url` parameter in the request, which contains the Interactive Authorization Endpoint that initiated the request. | |
| 1. The Wallet is able to detect that a request is not presented by the party that initiated the Interactive Authorization Request. In the case of the (#iae-require-presentation) interaction with a signed Presentation request, this is achieved by the Wallet verifying the `expected_url` parameter in the Interactive Authorization Response, which contains the Interactive Authorization Endpoint that initiated the Interactive Authorization Response. |
4 participants
Fixes #672
Fixes #698
Need feedback on whether
expected_urlshould be plural/ an array. Currently, it is a single value since there is only one IAE endpoint and follow-up requests have to use the IAE endpoint and not a dynamic URL provided by the interactive authorization response that requires interaction. If this should change any reasons (e.g. reusability), I would need to update the PR.@GarethCOliver if this should be a resuable mechanism, do we need to change the binding the IAE endpoint sections? Currently, they are tightly coupled to IAE by using prefixes etc.