Is it possible describing this use case in a step-by-step-fashion?

Same idea here !
On our usecase (event ticketing), the step by step looks like this :

1. Go on your ticket page with your browser (after you buy it)
2. Browser ask permission to broadcast the ticket number via NFC
3. User accept and touch his smartphone to a NFC reader to validate his ticket
4. Browser stop broadcasting the ticket number.

The goal is to avoid having a native app and use browser to broadcast ticket number.

@TMesot It it [quite] possible that I completely misunderstand the plot, but it seems that the ticket page is on a PC (in most cases). This use case has already been dismissed and PC vendors have [accordingly] ceased supporting NFC as well.

Or do you mean that you buy via the mobile and then get something persistant (a cookie?) in return allowing you later use that with NFC? To me it sounds like a rather quirky solution where you manually have to get back to the purchase page.

I would consider a more thought-through solution where you buy with the mobile browser, but use the resource with a generic ticket app. It should work for door locks as well. This requires a protocol and filtering so that only the right receiver gets the ticket.

My idea for the HCE use case looks a bit different:

1. Go on your ticket page (installable PWA) with your mobile browser (no PC involved at all)
2. Search for the event your want a ticket for
3. Go to checkout
4. Login with your favourite auth method (email, facebook, etc.) which creates/uses a user id
5. Buy the ticket
6. After payment transaction has completed the webserver behind the ticket page generates a ticket id and adds this ticket id to the list of tickets for this user id within its own database
7. Later on the user taps a NFC tag or scans a QR code at the entrance of the event to open a event specific webpage. Or the user opens the ticket PWA from its home screen and clicks on a button within the event details which enters the same event specific webpage
8. The event specific webpage tells to user to stay on this page during NFC checkin and the page uses the WebNFC API to implement the HCE used in the following step
9. The user taps on a NFC reader/termnial which reads the user id from the emulated passive tag
10. The terminal connects to the ticket platform (via internet) and checks if the given user id has a valid ticket id

The basic idea is as long as the current webpage is open and in the foreground the browser can leverage the HCE implementation of the webpage.

If you add the ticket id to the emulated card combined with an offline first PWA the complete access control solution would also work offline but security would be difficult to implement.

The basic idea is as long as the current webpage is open and in the foreground the browser can leverage the HCE implementation of the webpage

This scheme has effectively already been solved through QR codes. It is used by airlines all over the world. You can surely do a sleeker and more efficient system using NFC, but WebNFC doesn't seem like the right tool for such work.

A remaining problem with HCE, is that (for example) executing EMV inside of a browser introduces security issues since EMV was designed to be carried out in certified terminals.

Note: there ARE things to be done here but it requires new protocols that are designed for the Web. The recently announced W3C WebAuthentication system is an example of that. The traditional smart card never made it on the Web which caused Google and some other entities to design a system which is compliant with the "Web Security Model". I believe this system (which also supports NFC), actually could be used "as is" for your application. That is, a ticket would be a cryptographic key for exclusive consumption by s specific domain.

Yes, WebAuthentication may even have solved the disposable hotel door key problem and that using no additional software or hardware on the client side! It would work off-line as well.

@cyberphone
The idea is to buy your ticket with PC or smartphone and then, use the smartphone at entrance for validation. We currently use QR Code inside PDF (send by email) or with dedicated page under "My account" part of web site after login showing the QR Code. The idea is on this specific page, the ticket ID encoded inside the QRCode can also be broadcasted via NFC Write. It's the same need as step 8 of @leolux

For us the HCE is not needed in our use case, we don't need the security needed by smartcard. The goal is only to broadcast an unique id which is validated server side by the NFC reader. QRCode works fine but you need people increase screen brightness and a good camera. With NFC, you could be able to do it whatever the environment condition are.

@TMesot @lcarcone The WebAuthentication folks spent years on creating a "Smart card for the Web". Probably for a reason.

Related: http://www.atimes.com/article/china-launch-e-id-cards-citizens-via-phone-qr-codes/

https://www.pymnts.com/news/mobile-commerce/2018/digital-ticketing-google-pay-mobile-wallet/

We just implemented NFC scanning for our Web Wallet here https://github.com/linuxserver/nano-wallet/ (thanks for all the work in the web-nfc project)

Given the major use case of people transferring funds phone to phone using insecure text data ( in this case just a string containing the destination address and amount) being able to broadcast a tag from the same interface as well as scan them is extremely useful if planning to completely replace QR codes with NFC for the transaction workflow.
This allows people to simply bump phones instead of scanning a QR presented on one phone with their camera.

If you are not familiar with the process or other payment platforms like WeChat pay you can see a basic demo here:
https://twitter.com/garrytan/status/966122234271051776?lang=en