DC API: Always use Origin for binding response #448
Conversation
Sakurann
requested review from
danielfett,
tlodderstedt,
davidz25,
c2bo,
leecam,
tplooker,
paulbastian,
awoie,
Sakurann,
martijnharing,
bc-pi and
hlozi
Implements option 5 from #395 (comment) The means that, for example, the aud value in the SD-JWT key binding is based on the Origin obtained for the platform, even in the case of signed requests. The Client Identified Scheme prefix on the value is retained in these cases, to avoid any potential mixup attack between these DC API responses and non-DC API responses to clients using OpenID Federation. The Client Identifier Scheme name is changed from 'web-origin' to just 'origin' as it may contain a native app identifier, as per #351. The "client_id" is removed from the mdoc OpenID4VPDCAPIHandover as it now serves no clear purpose. It is left unsaid whether the Wallet is required to validate the signature on signed requests in all cases, this is a policy decision for Wallets. This change allows Wallets to skip the validation but still return a response that the Verifier can successfully process, as there is no longer any uncertaintly over what would be used for `aud` in SD-JWT KB JWT or for `client_id` in the ISO mdoc OpenID4VPDCAPIHandover structure. closes #351 closes #395
jogu
force-pushed
the
dc-api-remove-clientid-in-responses
branch
from
fb638a0 to
995152a
Compare
|
|
||
| * `web-origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme if the request is not sent via the Digital Credentials API defined in (#dc_api). | ||
| * `origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses. |
There was a problem hiding this comment.
Shouldn't we remove this whole section? This is not about a client_id anymore - we are just changing what to put into aud for DC API?
| * `web-origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme if the request is not sent via the Digital Credentials API defined in (#dc_api). | |
| * `origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses. |
There was a problem hiding this comment.
@c2bo I did wonder about that, but it's defined that what goes into aud is the client_id, and we're back to the problem of putting something into client_id that I think we need to be clear if it was intended for a client that authenticated using federation (+ custom url schemes) or one authenticated using just web PKI (+ DC API), for the same reasons we originally put the client id scheme into the aud - there's no other way for clients to tell the difference between those two types of responses.
Or to put another way, we are defining a meaning for 'origin' client id scheme in the response, so it's important that people don't define an origin client id scheme that means something different, hence retaining the definition in the client id scheme section as it would eventually need to be registered in any future IANA registry of client id schemes.
If Federation was always prefixed (with something other than "https://") then I think using just the url would make sense.
There was a problem hiding this comment.
The alternative to say that in OID4VC over DC API, the audience of the credential presentation is the origin of the request and not the client identifier. That would require us to clearly split the spec in the "traditional" and the "DC" part including all security considerations.
There was a problem hiding this comment.
That feels like the better/cleaner approach to me, but a pretty big change - especially given the current timelines
There was a problem hiding this comment.
The alternative to say that in OID4VC over DC API, the audience of the credential presentation is the origin of the request and not the client identifier. That would require us to clearly split the spec in the "traditional" and the "DC" part including all security considerations.
I don't think we really have a defined concept of the "audience of the credential presentation" in our credential format profiles though - we'd have to either introduce that concept, or have separate text for "traditional" versus "DC" in the credential format profiles too.
There was a problem hiding this comment.
I don't think we really have a defined concept of the "audience of the credential presentation"
why? we do use a term audience (the Client Identifier of the Verifier) in the spec already.
That feels like the better/cleaner approach to me, but a pretty big change - especially given the current timelines
as an option, we could merge this PR and do this as part of a PR addressing #453 ? (cc @awoie )
There was a problem hiding this comment.
so basically, we want the aud value to be prefixed with origin:, right? (to basically prevent the attacks that made us turn client id scheme parameter into a prefix in the first place). in which case, i agree it makes sense to keep this, but I would like to see more explanation that just The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses. something like
The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses.
audclaims of the Verifiable Presentation MUST be the origin value prefixed withorigin:
There was a problem hiding this comment.
I've added a sentence of explanation like @Sakurann suggested.
|
|
||
| Every OpenID4VP Authorization Request results in a response being provided through the Digital Credentials API (DC API). The response is an instance of the `DigitalCredential` interface, as defined in [@!W3C.Digital_Credentials_API], and the OpenID4VP Authorization Response parameters as defined for the Response Type are represented as an object within the `data` attribute. | ||
|
|
||
| In places where the Client Identifier would be used in the response (for example, the `aud` value in a Key Binding JWT), the Origin MUST be used instead, prefixed with `origin:`. |
There was a problem hiding this comment.
This should go into a general description of the DC API profile. Here I would mention that client ids with authentication credentials can go into the request, but only for authentication/authorization purposes. The audience of the credential presentation is not affected by any of those client ids.
There was a problem hiding this comment.
agreed. made suggestion above
There was a problem hiding this comment.
I've rewritten this text and also added an explicit sentence about explaining the audience isn't affected by the client id in the request.
|
|
||
| * `web-origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme if the request is not sent via the Digital Credentials API defined in (#dc_api). | ||
| * `origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses. |
There was a problem hiding this comment.
so basically, we want the aud value to be prefixed with origin:, right? (to basically prevent the attacks that made us turn client id scheme parameter into a prefix in the first place). in which case, i agree it makes sense to keep this, but I would like to see more explanation that just The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses. something like
The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses.
audclaims of the Verifiable Presentation MUST be the origin value prefixed withorigin:
|
|
||
| Every OpenID4VP Authorization Request results in a response being provided through the Digital Credentials API (DC API). The response is an instance of the `DigitalCredential` interface, as defined in [@!W3C.Digital_Credentials_API], and the OpenID4VP Authorization Response parameters as defined for the Response Type are represented as an object within the `data` attribute. | ||
|
|
||
| In places where the Client Identifier would be used in the response (for example, the `aud` value in a Key Binding JWT), the Origin MUST be used instead, prefixed with `origin:`. |
There was a problem hiding this comment.
agreed. made suggestion above
Co-authored-by: Kristina <[email protected]>
Thank you! I've committed all your suggestions, a few I tweaked a little first. |
| @@ -574,7 +574,7 @@ Body | |||
|
|
|||
| * `x509_san_dns`: When the Client Identifier Scheme is `x509_san_dns`, the Client Identifier MUST be a DNS name and match a `dNSName` Subject Alternative Name (SAN) [@!RFC5280] entry in the leaf certificate passed with the request. The request MUST be signed with the private key corresponding to the public key in the leaf X.509 certificate of the certificate chain added to the request in the `x5c` JOSE header [@!RFC7515] of the signed request object. The Wallet MUST validate the signature and the trust chain of the X.509 certificate. All Verifier metadata other than the public key MUST be obtained from the `client_metadata` parameter. If the Wallet can establish trust in the Client Identifier authenticated through the certificate, e.g. because the Client Identifier is contained in a list of trusted Client Identifiers, it may allow the client to freely choose the `redirect_uri` value. If not, the FQDN of the `redirect_uri` value MUST match the Client Identifier without the prefix `x509_san_dns:`. Example Client Identifier: `x509_san_dns:client.example.org`. | |||
|
|
|||
| * `web-origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme if the request is not sent via the Digital Credentials API defined in (#dc_api). | |||
| * `origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme in requests. In OpenID4VP over the Digital Credentials API, the audience of the Credential Presentation is always the origin value prefixed by `origin:`, for example `origin:https://verifier.example.com/`. | |||
There was a problem hiding this comment.
Do we still need this scheme?
There was a problem hiding this comment.
I brought up the same question before (#448 (comment)) and this seems to be more of a placeholder so nobody use that as a scheme. It is technically not a real client id scheme (cannot be used in the request), but blocked for the response.
I don't really like it but I guess this is fine?
There was a problem hiding this comment.
Yes, what Christian said - client id schemes are basically defining prefixes to be used in two places:
- The client id parameter
- The
audvalue in responses
The origin: prefix is definitely used in "2" so I think to avoid any potential for future confusion it should be a "registered" client id scheme.
| @@ -574,7 +574,7 @@ Body | |||
|
|
|||
| * `x509_san_dns`: When the Client Identifier Scheme is `x509_san_dns`, the Client Identifier MUST be a DNS name and match a `dNSName` Subject Alternative Name (SAN) [@!RFC5280] entry in the leaf certificate passed with the request. The request MUST be signed with the private key corresponding to the public key in the leaf X.509 certificate of the certificate chain added to the request in the `x5c` JOSE header [@!RFC7515] of the signed request object. The Wallet MUST validate the signature and the trust chain of the X.509 certificate. All Verifier metadata other than the public key MUST be obtained from the `client_metadata` parameter. If the Wallet can establish trust in the Client Identifier authenticated through the certificate, e.g. because the Client Identifier is contained in a list of trusted Client Identifiers, it may allow the client to freely choose the `redirect_uri` value. If not, the FQDN of the `redirect_uri` value MUST match the Client Identifier without the prefix `x509_san_dns:`. Example Client Identifier: `x509_san_dns:client.example.org`. | |||
|
|
|||
| * `web-origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme if the request is not sent via the Digital Credentials API defined in (#dc_api). | |||
| * `origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme in requests. In OpenID4VP over the Digital Credentials API, the audience of the Credential Presentation is always the origin value prefixed by `origin:`, for example `origin:https://verifier.example.com/`. | |||
There was a problem hiding this comment.
I brought up the same question before (#448 (comment)) and this seems to be more of a placeholder so nobody use that as a scheme. It is technically not a real client id scheme (cannot be used in the request), but blocked for the response.
I don't really like it but I guess this is fine?
Co-authored-by: Torsten Lodderstedt <[email protected]>
Implements option 5 from #395 (comment)
The means that, for example, the aud value in the SD-JWT key binding is based on the Origin obtained for the platform, even in the case of signed requests.
The Client Identified Scheme prefix on the value is retained in these cases, to avoid any potential mixup attack between these DC API responses and non-DC API responses to clients using OpenID Federation.
The Client Identifier Scheme name is changed from 'web-origin' to just 'origin' as it may contain a native app identifier, as per #351.
The "client_id" is removed from the mdoc OpenID4VPDCAPIHandover as it now serves no clear purpose.
It is left unsaid whether the Wallet is required to validate the signature on signed requests in all cases, this is a policy decision for Wallets. This change allows Wallets to skip the validation but still return a response that the Verifier can successfully process, as there is no longer any uncertaintly over what would be used for
audin SD-JWT KB JWT or forclient_idin the ISO mdoc OpenID4VPDCAPIHandover structure.closes #351
closes #395