The request context struct currently only includes the top-level origin. In cross-origin iframe scenarios (e.g., an embedded verification service), the document origin can differ from the top origin. Including both origins would allow the digital credential chooser and holder to make informed trust decisions about which party is actually requesting the credential, not just which top-level site is hosting the request.
This was removed from the present the credential request algorithm in PR #419 because:
- CTAP compatibility: The CTAP protocol spec currently accepts only one origin. Sending both origins in cross-device flows would require a CTAP spec change.
- Implementation gaps: Chromium does not currently send either origin explicitly in its mojo struct (origins are implicit in the browser process context). WebKit carries both origins through IPC but only forwards the top origin to the platform API (
WKIdentityDocumentPresentmentRequest initWithOrigin: takes a single origin).
Once CTAP supports multiple origins and platform APIs are updated, the document's environment settings object's origin should be added back to the request context as a separate field.
The
request contextstruct currently only includes the top-level origin. In cross-origin iframe scenarios (e.g., an embedded verification service), the document origin can differ from the top origin. Including both origins would allow the digital credential chooser and holder to make informed trust decisions about which party is actually requesting the credential, not just which top-level site is hosting the request.This was removed from the
present the credential requestalgorithm in PR #419 because:WKIdentityDocumentPresentmentRequest initWithOrigin:takes a single origin).Once CTAP supports multiple origins and platform APIs are updated, the document's
environment settings object's origin should be added back to the request context as a separate field.