Skip to content

Add origin checks in exchange.start({event}) #71

@dlongley

Description

@dlongley

When CHAPI is used with a non-OOB request (bedrock-web-wallet generally does not use OOB requests) then whatever the value is in the exchange event's credentialRequestOrigin property should "safely provided" and the origin for that URL is what can be surface to a user for them to check whether they want to trust the request or not.

For QR codes and any other OOB requests, the situation is different. The credentialRequestOrigin will have to be parsed from the scanned URL or the passed protocol URLs, in a protocol-url-specific way. We will want each individual protocol handler to handles this and surface the origin in the exchange interface created from exchanges.start({event}). For protocols that support signed requests, this can be based on the signer of the request.

For the VC API protocol cases:

  • If a VC API "interaction URL" is used (a VC API exchange URL that ends in /protocols), then the origin must match the credentialRequestOrigin. To enforce this, we should log an error and refuse to use a non-matching origin URL.
  • For the VC API QR code case, using an interaction URL is the only way that VC API should be executable, a bare exchange ID URL should NOT be considered valid (and this should be enforced similarly to the first bullet point). Note that the interaction URL origin in the QR code case is the only origin that matters, not whatever origin is used within the result of fetching the "protocols" object (which can safely be any origin) from the interaction URL.
  • In the longer term, we might want to require that any vcapi URL passed from CHAPI MUST have the same origin as credentialRequestOrigin (even if it does not end in /protocols) once there are no legacy interoperability concerns, just to maximize security.

The rules are a bit different for OID4* URLs. If received via a non-OOB request from CHAPI, then the credential request origin should be trusted regardless of what origin is ultimately within the OID4* URL. For all other cases (OOB / QR code), the origin of the URL parsed from the credential_offer_uri, the credential_offer.credential_issuer (for OID4VCI), or the client_id (for OID4VP) provide the credential request origin value. However, for OID4VP, the authorization request will have to be retrieved and checked to see if it was signed or not -- which can change what the origin is (to be whatever the signer ID's origin is).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions