Meeting minutes
Updates from the OpenID Foundation
[Slides from Kristina and Torsten]
Kristina: Torsten and I are co-chairs of digital credentials protocols wg in OIDF
… today we'll mostly talk about openid4vp and openid4vci
Kristina: Vertical profiles sit upon the protocols.
… plan is to publish 1.0 final of openid4vp, openid4vci, and HAIP around June 2025. After that we will not make breaking changes after 1.0
Kristina: We have lots of interop events happening
… if you want to read the specs: VP=>24; VCI=>ID-2; HAIP=>iD-1 (coming soon)
Kristina: There's a lot of introductory material about the APIs online.
… hot topics today are:
- DCQL (query language) enhancements
… this came as a close collaboration with the Digital Credentials API
… the wallet and verifier now have direct communication
… more on Transaction data => binding user interaction with how the user authenticated.
Kristina: We now have support for multi-relying party requests
… and wallet attestation during presentation
… attestation is more important at issuance, but there are use cases for presentation as well.
Torsten: Regarding transaction data for payment authorization
… this was introduced in summer 2024 for two use cases
… using capabilities of the wallet to bind a decision of the user of the wallet with a certain transaction (e.g., transaction confirmation, signing a contract)
… the wallet shows it to the user and the user signs the data with a key that is bound to a certain credential.
… thus, we bind the identity and the decision.
… the request is a presentation request (the RP asks for the presentation of a credential)
… on top of that, they ask to display some terms and conditions for the user's agreement
… the wallet creates the proof of possession to sign a presentation object
… this object would include the displayed data, which is sent back to the relying party (the merchant, for example)
(Torsten shows JSON representation of dcql query and transaction_data)
… the response (the sd-jwt) includes the confirmation claim ("cnf") that includes the public key used to do the proof of possession.
Torsten: We are discussing 2 use cases: use of feature to authorize a credit transfer and (2) payee-requested flow.
… in case 1, the wallet is the bank's wallet (so the bank has evidence of consent of the credit transfer).
… for payee-requested flow, the bank provisions the credential into the wallet, but then the presentation request is sent by a merchant.
… the merchant gets back a presentation, which authorizes the payment, and then the merchant can put that in their payment API
<Zakim> smcgruer_[EST], you wanted to ask (1) about structure of PaymentRequest data, (2) what happens if the wallet doesn't reply with support (or if there is no wallet)
smcgruer_[EST]: On the PaymentRequest object; one thing we've heard with SPC (which is similar) is a lot of demand to meet other use cases like recurring payments.
… we've struggled how to encoded those use cases in structured data
Torsten: That's our experience as well. We as OIDF don't standardize payments; just the rails.
… we have defined a transaction data feature as an extension point (with a "type" attribute)
… EWC is one of the LSPs in Europe looking at the payments use case.
… and the use of the transaction data
… there's a lot of testing going on right now in the EU. Kristina and I are involved, and are providing prototypes to the LSPs.
… we'll be testing this year.
smcgruer_[EST]: What if the wallet doesn't support the "type"?
… what happens if no wallet is appropriate or replies?
Torsten: If a wallet doesn't support a transaction type, it refuses.
Gerhard: We've also defined in the WPWG a structure. Should we go to OIDF to get an SPC payload data standard?
… how to standardize different transaction data formats?
Torsten: that's an important question. We haven't really decided on that yet. I think it makes sense to have a list of definitions. But I don't think OIDF will do the definitions.
Ian: Any discussion of type being a URL?
Torsten: Yes
[Torsten drops off]
(We look at QES in QTSP centric model)
Kristina: The dcql_query is top-level transaction data. The transaction_data uses a URL-based type, and the transaction data can be bound to whatever the credentials the user has (so it's an array)
… there are a number of claims defined by the type
… and a hashAlgorithm specification that will go in the response.
… we are looking to change the response structure to make it more credential format agnostic.
… our use cases are mostly around sd_jwt. If there is interest in using mDOCs or other credential format, that should be discussed.
[On OpenID4VCI]
Kristina: the biggest update is batch issuance of credentials.
… if the user keeps presenting the same credential everywhere, that may lead to tracking.
… batch issuing varies the signature to reduce risk of tracking.
… another important feature is wallet attestation and key attestation
… it's an important security feature that the key has been validated by the issuer.
… another important topic is credential lifecycle.
… we differentiate "credential configuration"; the actual credential where the data is filled in already, and the copy of each credential.
… so for example, one might issue 3 educational diplomas where there are minor variations but the same schema
… we also simplified the protocol to remove unused features.
… we are still working on some topics: (1) deferred issuance (2) cleanup
… for example, in some cases, one might authenticate the user and then issue credentials 24 hours later.
… in general the specs allow for different architectures (e.g., with or without wallet backend)
Kristina: We are aware that the work of issuance over browser API is also happening.
… issuance can involve a wallet selection challenge
Fahad: can an issuer indicate what wallet they want to store the credential in (in issuance)?
Kristina: Issuance is much closer to the Oauth model.
… when the wallet sends a token request to the token endpoint, that's where the wallet attestation kicks in
… in the EU we expect that the wallet instance running on the user's device will have an attestation that the wallet is certified by the German government, for example.
… the issuer will get the attestation.
… and can make a decision
… but the protocol may also support preferences in the metadata
Fahad: the use case we have: we have two banks. Bank 2 is issuing a credential and wants its credential to go to their wallet. If there's no mechanism, it will be weird for the user.
… so we need to enable the issuer to target a particular wallet.
Kristina: Can you use claim URLs for that use case?
Fahad: The assumption is that the payment profile is standardized. So two wallets could say "we support this type of credential"
Kristina: This problem is not solved in the MDL profile, for example. This could be solved in a payment specific use case.
… but I think the URL is best way forward
… OAuth works like that - you know the client you want to work with and can pre-exchange metadata.
… if you know 1-1 matching, that's easier to implement.
[We look at HAIP (High Assurance Interoperability Profile) updates]
… now a collection of 4 profiles that can be used independently (including using Digital Credentials API)
Kristina: In the ipenid4vp spec, section 9 (Wallet Invocation) supports URLs as domain-bound as authorization_endpoints.
… this would support opening of a targeted wallet.
Ian: Any alignment possible between the SPC data model and transaction data type=PaymentRequest?
Rouslan: I think it would be useful to align data models and descriptions.
smcgruer_[EST]: I think it is useful to align the data model. But we should figure out who are working on the transaction model for alignment.
… in SPC we are going to be adding information about the issuers (e.g., logos) in the UX
… but that may not be necessary in digital wallet context since the wallet is expected to have the context
… so presenter of data may be different in SPC case than in wallet case.
… but there might be use cases where there is overlap.
… maybe there are cases where information is not yet associated with a credential.
(We talk about UX of digital wallet selector)
Kristina: We know there are issues with wallet selection and cross-device security.
… we need *some* API to solve these
… in rechartering discussion some ideas for discussion are (1) profile (2) registry
… transaction data is a small piece. We'd like to make sure that the HAIP matches your own needs
… and there might be a profile that is created "Use HAIP this way for this use case"