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/2e6eb4fa-7f31-482d-b497-e20b3b336899n%40chromium.org.

Reply via email to