For the thread, Mohamed has now proposed shipping <https://groups.google.com/a/chromium.org/g/blink-dev/c/B60Wx2mNtw4> this API instead of extending the OT and I agree that's a better plan at this point.
On Wed, Aug 26, 2026 at 11:31 AM Alex Russell <[email protected]> wrote: > Hey Mohamed, > > We discussed at this morning's API OWNERs call and agreed this is an > uncomfortable end-to-end timeframe for an OT without breaking changes. > Teams should not treat OT as a "soft launch" tool for features that are > perennially *almost* ready, modulo one tweak. This is why we ask folks to > summarize OT feedback to date if/when they ask for extensions. I understand > that this is particularly complex because it involves cross-device flows > and third parties, but staying in a holding pattern for a year+ risks both > burn-in to the web platform and burn-out of the team. > > OT is one tool among several to build confidence in a design. Presumably > there has been some use of the feature in the year+ since it went to OT, > and presumably much private discussion with developers besides. OT isn't > meant to be a gate, it's a learning mechanism to understand if the design > meets developer needs. If it's failing at that, I'd encourage you to build > confidence in other ways, or if you have alterative evidence to bring that > as collateral instead to an I2S thread. > > For the health of your feature and your team, I'm inclined not to approve > this OT until/unless there is an I2S filed for the feature with an intent > to run a gapless OT. That is, you are being *strongly* encouraged to ship > and make compatible additions to the baseline API from here. Alternatively, > you might get permission for a future OT by either implementing breaking > changes or proposing, at a minimum, a one (1) release breakage period where > your feature becomes unavailable and then returns to OT. > > Maybe there are mitigating circumstances here that I don't understand; if > so, please reach out and we can discuss. > > Best, > > Alex > > > On Monday, August 24, 2026 at 1:34:52 PM UTC-7 Mohamed Amir Yosef wrote: > >> Thanks Alex for the quick feedback! >> >> Yes, it is indeed a long OT, but most of the time was wasted because of >> partner delays. >> >> Regarding the issue, >> https://github.com/w3c-fedid/digital-credentials/issues/382 >> The current proposals are indeed not a breaking change, and can indeed be >> added later. >> However, it's not yet clear which proposal will be spec'ed. For example, >> one of the other proposals is to block cross-device issuance, which will be >> a breaking change. >> My intuition was that extending for three more months while we gain >> clarity is safer than shipping now and potentially having to live with the >> consequences. >> >> WDYT? >> >> >> On Mon, Aug 24, 2026 at 9:02 PM Alex Russell <[email protected]> >> wrote: >> >>> This is an uncomfortably long OT end-to-end. If you're able to ship >>> before the end of this extension, I would encourage you to do so. >>> >>> Also, why would this issue present a breaking change? Wouldn't it be >>> possible to ship now and then add interoperable extensions on top of the >>> shipped surface?: >>> >>> https://github.com/w3c-fedid/digital-credentials/issues/382 >>> >>> Why aren't we launching instead of extending the OT? Is there really >>> *no* useful OT feedback? >>> >>> Best, >>> >>> Alex >>> >>> >>> On Monday, August 24, 2026 at 11:48:33 AM UTC-7 Chromestatus wrote: >>> >>>> *Contact emails* >>>> [email protected], [email protected], [email protected] >>>> >>>> *Explainer* >>>> https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md >>>> >>>> *Specification* >>>> https://w3c-fedid.github.io/digital-credentials >>>> >>>> *Summary* >>>> This Web Platform feature enables issuing websites (e.g., a university, >>>> government agency, or bank) to securely initiate the provisioning >>>> (issuance) process of digital credentials directly into a user's mobile >>>> wallet application. On Android, this capability leverages the Android >>>> IdentityCredential CredMan system (Credential Manager). On Desktop, it >>>> leverages cross-device approaches using the CTAP protocol similar to >>>> Digital Credentials presentation. >>>> >>>> *Blink component* >>>> Blink>Identity>DigitalCredentials >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EIdentity%3EDigitalCredentials%22> >>>> >>>> *Web Feature ID* >>>> Missing feature >>>> >>>> *TAG review* >>>> https://github.com/w3ctag/design-reviews/issues/1119 >>>> >>>> *TAG review status* >>>> Pending >>>> >>>> *Origin Trial Name* >>>> Digital Credentials API - Issuance Support >>>> >>>> *Goals for experimentation* >>>> We want to gather initial feedback from production usage of end-to-end >>>> scenarios involving at least one wallet and at least one real-world issuer >>>> website including the cross-device flow. One of the initial use cases of >>>> digital credentials issuance via the origin trial will be the Sparkasse age >>>> credential in Google Wallet. Sparkasse is a network of regional German >>>> savings banks with more than 50 million customers. Sparkasse will issue >>>> their customers an 18+ age credential from their website based on verified >>>> information with the bank to Google Wallet, that can be used online to >>>> prove their adulthood with websites and apps online >>>> >>>> *Chromium Trial Name* >>>> WebIdentityDigitalCredentialsCreation >>>> >>>> *Origin Trial documentation link* >>>> https://w3c-fedid.github.io/digital-credentials >>>> >>>> *WebFeature UseCounter name* >>>> kIdentityDigitalCredentialsCreation >>>> >>>> *Risks* >>>> >>>> >>>> *Interoperability and Compatibility* >>>> There are multiple standards efforts involved here. We have been >>>> working with WebKit and Mozilla in the WICG on defining this specific API. >>>> But the greater interoperability risk will come from the data that is sent >>>> and returned via this API. Details of that are driven outside the web >>>> browser community in the OpenID Foundation. >>>> >>>> *Gecko*: Negative ( >>>> https://github.com/mozilla/standards-positions/issues/1003) >>>> >>>> *WebKit*: Support ( >>>> https://github.com/WebKit/standards-positions/issues/332) Presentation >>>> support is shipped, but timeline for adding issuance support yet. >>>> >>>> *Web developers*: No signals >>>> >>>> *Other signals*: >>>> >>>> *Activation* >>>> The primary activation concern is enabling existing deployments using >>>> technology like OpenID4VCI to be able to also support this API. As such we >>>> have left the request protocol unspecified at this layer, to be specified >>>> along with existing request protocols to maximize activation opportunity. >>>> >>>> *WebView application risks* >>>> >>>> Does this intent deprecate or change behavior of existing APIs, such >>>> that it has potentially high risk for Android WebView-based applications? >>>> *No information provided* >>>> >>>> >>>> *Reason this experiment is being extended* >>>> - Our main partner on DC issuance experienced some delays and hence >>>> couldn't start the experimentation on time. - We are making progress on the >>>> spec. However, we would like more time experimenting with the feature >>>> before shipping it in Chrome. Specifically, we have two issues that we >>>> would like to resolve before shipping in Chrome to avoid breaking changes. >>>> https://github.com/w3c-fedid/digital-credentials/issues/382 and >>>> https://github.com/w3c-fedid/digital-credentials/issues/356 >>>> >>>> *Reason this experiment is being extended* >>>> We request an extension because all planned partner participants have >>>> experienced delays, resulting in insufficient time to gather the necessary >>>> feedback on the feature. >>>> >>>> *Reason this experiment is being extended* >>>> Partners made great progress and they are shipping a use case that is >>>> using the API, and this should be enough signal to ship the DC API Issuance >>>> support in Chrome. However, there is one pending issue >>>> https://github.com/w3c-fedid/digital-credentials/issues/382 that get a >>>> lot of controversy. I'd rather extend the OT for one more time to get >>>> clarity regarding that issue instead of shipping the API without clarity in >>>> that regard. In the meanwhile, the discussion is active on the issue and I >>>> am pushing for a resolution in the WG, and hoping we can experiment with a >>>> solution in Chrome within the boundaries of this extension. >>>> >>>> *Ongoing technical constraints* >>>> *No information provided* >>>> >>>> *Debuggability* >>>> None necessary - just new JS API. For testing we plan to add a >>>> developer option to provide a fake wallet, but this effort is still >>>> ongoing. >>>> >>>> *Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>> No >>>> >>>> *Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>> Yes >>>> >>>> https://wpt.fyi/results/digital-credentials?label=experimental&label=master&aligned >>>> >>>> *Flag name on about://flags* >>>> web-identity-digital-credentials-creation >>>> >>>> *Finch feature name* >>>> WebIdentityDigitalCredentialsCreation >>>> >>>> *Requires code in //chrome?* >>>> True >>>> >>>> *Tracking bug* >>>> https://crbug.com/378330032 >>>> >>>> *Launch bug* >>>> https://launch.corp.google.com/launch/4418038 >>>> >>>> *Estimated milestones* >>>> Origin trial desktop first 143 >>>> Origin trial desktop last 148 >>>> Origin trial extension 1 end milestone 154 >>>> Origin trial extension 2 end milestone 151 >>>> Origin trial extension 3 end milestone 160 >>>> DevTrial on desktop 133 >>>> Origin trial Android first 143 >>>> Origin trial Android last 148 >>>> DevTrial on Android 133 >>>> >>>> *Link to entry on the Chrome Platform Status* >>>> https://chromestatus.com/feature/5099333963874304?gate=6278421599617024 >>>> >>>> *Links to previous Intent discussions* >>>> Intent to Experiment: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68ed3208.050a0220.30571e.0360.GAE%40google.com >>>> Intent to Extend Experiment 1: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a42465a.198129d7.8452e.0378.GAE%40google.com >>>> Intent to Extend Experiment 2: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69c3e985.050a0220.38bee9.051b.GAE%40google.com >>>> >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://chromestatus.com>. >>>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-OiZA8AuiPcC4jmBF%3DM58dY0ALPBOA7bVzvMfyuYbKng%40mail.gmail.com.
