[Digital Credentials] Validate OpenID4VP requests and hand them to the picker

Component: WebCore Digital Credentials | dcbc358

LayoutTests/http/wpt/identity/formats/openid4vp/openid4vp-roundtrip.https-expected.txt

-PASS openid4vp-v1-signed request: virtual wallet response is passed through with correct protocol and data.
-PASS openid4vp-v1-multisigned request: virtual wallet response is passed through with correct protocol and data.
-PASS Mixed mdoc + openid4vp-v1-signed request: virtual wallet can respond with a specific protocol.
-PASS openid4vp-v1-signed request: virtual wallet decline rejects with NotAllowedError.
-PASS openid4vp-v1-signed request: wait + abort rejects with AbortError.
+PASS openid4vp-v1-signed: roundtrip passes through response data.
+PASS openid4vp-v1-multisigned: roundtrip passes through response data.
+PASS openid4vp-v1-unsigned: roundtrip passes through response data.
+PASS openid4vp-v1-signed: decline rejects with NotAllowedError.
+PASS openid4vp-v1-signed: wait + abort rejects with the abort reason.
+PASS Mixed mdoc + openid4vp request: mdoc takes precedence.

LayoutTests/http/wpt/identity/digital-credential-openid4vp-disabled-by-default.https.html

+

Digital Credentials API를 사용하면 페이지가 protocol 태그가 붙은 request로 navigator.credentials.get()을 호출할 수 있습니다. protocol로는 org-iso-mdoc, openid4vp-v1-signed 등이 있습니다. 먼저 WebContent가 이 request를 parsing하고 검증합니다. 이후 UI process가 picker를 띄우고 플랫폼의 identity document 서비스와 통신합니다. 이때 UI process는 검증된 데이터를 IPC로 직렬화된 DigitalCredentialsRequestData 형태로 전달받습니다. 즉 UI process 쪽 decoder가 trust boundary에 해당합니다. 한편 raw request는 document provider에도 그대로 전달되며, provider는 각 request를 위치로 식별합니다.

이번 commit에서 WebContent는 각 OpenID4VP request를 검증해 ValidatedOpenID4VPRequest로 변환하도록 변경되었습니다. 여기에는 protocol, DCQL query, 서명에서 추출한 verifier identity가 담기며, mdoc 데이터와 함께 직렬화됩니다. picker는 이를 다시 WKIdentityDocumentPresentmentOpenID4VPRequest로 매핑합니다. 처리 규칙도 함께 정해졌습니다. mdoc이 우선하고, OpenID4VP protocol은 하나만 제시됩니다. provider로 넘어가는 raw request는 제시된 request와 순서까지 정확히 일치해야 하며, 일부만 일치하는 경우는 허용되지 않습니다. 다만 검증에 실패한 request도 virtual wallet이 응답할 수 있도록 계속 전달됩니다. virtual wallet이 아닌 경우에는 picker 단계에서 reject됩니다. 이 preference는 HAVE(DIGITAL_CREDENTIALS_OPENID4VP)가 정의된 환경에서 기본으로 활성화되었습니다.

Significance

페이지가 제어하는 JSON이 sandbox된 WebContent process에서 UI process를 거쳐 system document provider까지 전달되며, 이 경로가 기본으로 활성화되어 있습니다. 전달되는 데이터에는 DCQL query, claim path, trusted authority 목록, certificate 데이터가 포함됩니다.

Audit directions

Decode 단계의 제한 동등성. WebContent가 compromise된 경우 builder를 거치지 않고 struct를 직접 전송할 수 있습니다. 따라서 isWithinOpenID4VPRequestLimits와 문자열 길이, element 개수, 최대 제시 개수 제한이 IPC decoder에서도 동일하게 성립해야 합니다. 모든 nested container가 점검 대상입니다.
검증되지 않은 request의 전달. 검증 실패 경로에서 UI process가 각 필드에 대해 어떤 전제를 두는지 살펴볼 필요가 있습니다. 이와 함께 virtual wallet 분기와 picker reject 분기가 해당 필드를 일관되게 다루는지도 확인해야 합니다.
위치 기반 매칭. raw request는 index 기준으로 제시된 request와 짝지어집니다. 그래서 mdoc 우선 처리, protocol 선택, truncation 주변에서 off-by-one과 불일치 케이스를 시험해 볼 필요가 있습니다. 새로 추가된 RejectsValidationThatDoesNotCoverEveryRequest 테스트 역시 개수 불일치를 가리킵니다. 또한 실제로 요청된 protocol에 대해서만 response가 수락되는지 확인해야 합니다.
Bridging 계층. mapClaimsQuery, mapStringSets, mapCertificateChain, buildValidatedOpenID4VPRequestObject, convertClaimPathComponent, convertClaimValue를 점검할 필요가 있습니다. 주요 확인 대상은 lifetime, nil 처리, variant type confusion입니다. 한편 soft-link된 WebKitSwift symbol이나 WebKitAdditions가 없을 때의 동작도 함께 살펴봐야 합니다.