Rework transaction data architecture across protocols and formats. - #1981
Merged
Conversation
Contributor
Author
|
SwiftUI consent prompt: |
Contributor
Author
|
Compose consent prompt: |
davidz25
force-pushed
the
transaction-data-fixes
branch
2 times, most recently
from
September 5, 2026 13:48
3457ba0 to
d5dfbda
Compare
Previously, transaction data handling attempted a one-size-fits-all model largely derived from early OpenID4VP transaction concepts. This approach struggled to accommodate the divergent transport, data encoding, and cryptographic requirements between presentation protocols and credential formats, and did not align with the ISO/IEC 18013-5 Second Edition draft. Refactor transaction data architecture by decoupling lifecycles across all four combinations of (ISO/IEC 18013-5 vs OpenID4VP) x (ISO mdoc vs SD-JWT VC): - ISO/IEC 18013-5 with ISO mdoc: Standardize requests and device-signed responses under the "org.iso.transactiondata" namespace per the Second Edition specification, nesting responses by transaction identifier and validating element-level device key authorizations in the MSO. - OpenID4VP with ISO mdoc: Handle transaction requests via DCQL and produce flat device-signed elements under dedicated OpenID4VP response namespaces. - ISO/IEC 18013-5 with SD-JWT VC: Embed transaction hashes and inputs within the Key Binding JWT (KB-JWT) keyed by document request identifiers. - OpenID4VP with SD-JWT VC: Bind transaction hashes and user inputs directly into top-level claims of the KB-JWT. Refine device key authorizations and query matching: - Treat device key authorizations as issuer-defined security policies in the MSO rather than static schema properties of document types, scoping authorizations to specific elements to prevent unauthorized transactions. - Support claims-less credential queries across DCQL and presentment sources for transaction-only or authentication presentment. - Update the Android Credman matcher engine to parse IEEE 754 floating-point numbers in CBOR, resolve device-signed claims without displaying them in the picker, and match transaction claims for SD-JWT credentials. Modernize consent prompt user interfaces in Compose and SwiftUI: - Move transaction details below requested claims and remove container boxes. - Add contextual approval headings based on the presence of claims. - Use platform icons (Material Outlined in Compose, SF Symbols in SwiftUI). - Display currency amounts with in-place tip breakdowns and replace dropdown menus with adaptive filter chips. Additionally, support client-provided origins in verifier endpoints and add payment transaction demonstration scenarios across sample apps. Fixes #1980. Test: Manually tested on Android and iOS. Test: Ran ./gradlew :multipaz:jvmTest Test: Ran ./gradlew :multipaz-compose:assemble Test: Ran ./gradlew detekt Test: Ran xcodebuild -project samples/SwiftTestApp/SwiftTestApp.xcodeproj -scheme SwiftTestApp -sdk iphonesimulator build Signed-off-by: David Zeuthen <zeuthen@gmail.com>
davidz25
force-pushed
the
transaction-data-fixes
branch
from
September 5, 2026 14:25
d5dfbda to
b0936bf
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously, transaction data handling attempted a one-size-fits-all model largely derived from early OpenID4VP transaction concepts. This approach struggled to accommodate the divergent transport, data encoding, and cryptographic requirements between presentation protocols and credential formats, and did not align with the ISO/IEC 18013-5 Second Edition draft.
Refactor transaction data architecture by decoupling lifecycles across all four combinations of (ISO/IEC 18013-5 vs OpenID4VP) x (ISO mdoc vs SD-JWT VC):
Refine device key authorizations and query matching:
Modernize consent prompt user interfaces in Compose and SwiftUI:
Additionally, support client-provided origins in verifier endpoints and add payment transaction demonstration scenarios across sample apps.
Fixes #1980.
Test: Manually tested on Android and iOS.
Test: Ran ./gradlew :multipaz:jvmTest
Test: Ran ./gradlew :multipaz-compose:assemble
Test: Ran ./gradlew detekt
Test: Ran xcodebuild -project samples/SwiftTestApp/SwiftTestApp.xcodeproj -scheme SwiftTestApp -sdk iphonesimulator build