Support ISODep

[Liryna]

Hi,

There is a draft for the IsoDep communication in w3c wiki (2012). https://www.w3.org/wiki/Draft_APDU_API

It seems that it is not include and even not mention in w3c/web-nfc, is there any reason ? Sending direct APDU command to smartcard supporting it (NFC Forum Type 4, DESFire,...) would really enhance the possibilities.

I can make a PR to add it if there is no real reason that it is missing.

[kenchris]

This is basically due to focus, ie. we want to get the core functionality right first and get by in from different browser vendors. Aiming too high in web standards often means that the specs ends up never getting implemented. After getting the current feature set implemented in at least two browsers and getting feedback, we will start working on v2 and look at these things.

[Liryna]

Thank you for you clear answer @kenchris

I understand your point of view and I agree that the v1 should be simple to 'attract' browsers. However I think this should be in mind's devs that will implement v1 because IsoDep is only a question of abstractions and opening the API.

[kenchris]

We already looked at this before, so initial discussions has already happened offline. Web NFC is currently being implemented in Chrome, and Alex who is doing the implementation is well aware of how NFC works and what is possible.

The experimental implementation is taking a bit longer than anticipated as clean ups are happening in Chrome (Project Onion Soup) but we hope to have something ready soon. We also hope that other vendors will soon start experimenting with the current API, so that we can move on to the v2 feature set.

Thanks for your interest in the spec.

If you want to contribute with use-cases for this extension, or API suggestions, feel free to do that.

[zolkis]

When it comes to the SE API, that's for v2, needing web-specific use cases.

NFC Forum Type 4 is mentioned in the spec. If there is support for it in the underlying platform, implementations may support it, but this API does not intend to provide a low level access.

Security is one of the main reasons the Web NFC API is a more like a special way of using NFC, and not a low level NFC API. The Web NFC API should be usable from web pages, using the browser security model.

When you have a web runtime with well defined application and store security, you can use a low level API such as the W3C NFC API -- although that doesn't support SE either. But in browsers it's a different, slower developing story.

The Web NFC API is extended based on use cases, and not so much on generic mapping of protocols to the Web. When considering support for a use case, we need to analyze how does it affect security and privacy, and how can we expose it in a simple way to web pages.

So rather than providing a generic low level secure element API, we'd prefer focusing on a few key use cases concerning SEs. If you have use cases in mind, please open issues for them.

[Maxhy]

Got your points here. I can agree with the scope that should be limited in its first version to see faster a real implementation ; with the risk that a second version would takes decade ; but I'm more skeptic about security and privacy arguments here.

Basically Web NFC API provides read/write capabilities to external devices. When we talk only about tags, there is millions of RFID chips out there using the same technologies that what we call today NFC is based on, for e-ticketing, access control and banking industries. If you don't provide a low level NFC API then there is good probabilities that you will see the birth of a new de-facto Web NFC API Wrapping protocol based on HCE emulation, JCOP applet and new RFID/NFC chips. Coming from these industries I would be at least one of these guys going this way so I'm pretty sure there will be others. My thoughts is that you will just delay the problem if this is one, and divide at little bit more the industry which already has some difficulties to stay on standardized roads.

[kenchris]

Point taken.

It is possible to start iterating the required API additions before actually adding it to the spec (to not delay implementations of v1), but as Zoltan pointed out, W3C standards are attempting to be very use-case oriented today so a first step would be for you to clearly define these use-cases for us, preferable in separate GitHub issues. Suggestions on how you would like the API to look and how to make it safe, are also very welcome.

[anssiko]

@Maxhy @Liryna I'd encourage you to provide your use cases as input to this group. Any format will do, and probably the easiest way for you is to simply open a new GH issue with your input that can be discussed in the group. Please note that this group is currently chartered to define browser-safe Web NFC API, thus tighter scope. You may also want to review the use cases that were used as a basis for the v1 spec (note: Handover to Bluetooth was deemed out of scope for v1).

[zolkis]

@Maxhy @Liryna The security & privacy points were critically important for browser makers. As I said, this is a browser API. It is tricky to grant any web page e.g. the payment ability (even if the user blindly clicks yes to a security dialog).

The document you have linked refers to the W3C System Applications and NFC working groups. Both are dead now, since the lack of a suitable web security model that would be accepted by browser makers. That means it was not possible to evolve the specs through the formal standards track required by W3C.

As I said, all of those APIs are fine in a web runtime, which seems to be your use case. I don't argue about the need of standardizing JS APIs for runtimes etc - actually that need is skyrocketing nowadays - , but at the moment this seems very difficult to do within the W3C. The only way to do it is to forget thinking in terms of JS runtime platforms, formulate the use cases in terms of web pages run in browsers, and try to convince at least 2 independent browser makers to implement the spec. You can then implement the resulting standardized API in a web runtime as well.

Apart from that, the API you are requesting is quite simple, it's included in the charter and I don't see many divergence possibilities: just use Promises and make it simpler than in that document. I wonder if it could be exposed as a separate root object, and requiring a different permission than 'nfc'. It could also go to a different group report (specification), in order to separate the concerns.

What NFC backend would you be interested to use for implementing the API you need?

We could support an SE API on Android/Chromium, and Linux/Chromium using neard, see the neard SE and SE manager API. HCE is not supported yet by neard, and Android has limitations as well.

[alexshalamov]

@zolkis @kenchris I can experiment with existing API and for example, extend watch() operation. Using different NFCWatchOptions, user can select technology criteria (NDEF or ISODep). If ISODep is selected and device in proximity supports it, handle for communication will be provided.

I can experiment and report my findings. What do you think?

[zolkis]

We can discuss this as a future feature, but this proposal sounds good. We need to check the security implications, and how underlying platforms would handle the security threats. I think it may be similar to the threats already existing with the current API (e.g. with media content), but we need to dig deeper.

[anssiko]

The first task would be to briefly document possible use cases for the ISODep feature.

The feature is good to be experimented with assuming there are valuable use cases for the Web and it can be implemented in browsers that adhere to the Web's security model. Also beneficial would be to understand possible security threats, so that we can look into mitigation strategies early on.

@zoltan @kenchris, if you plan to bake this into the spec, you should mark it as an experimental feature to delineate it from from API surface that is considered more stable and is implemented already.

@Liryna, if you plan to make substantive contributions, please join the Web NFC Community Group. I noticed couple of your colleagues are already participants.

[cyberphone]

The feature is good to be experimented with assuming there are valuable use cases for the Web and it can be implemented in browsers that adhere to the Web's security model

This is where it gets difficult. The majority of valid use cases would build on using a mobile phone to approach a PC Web page. The phone already has a security model. Having both the browser and the phone ask for accept by the user would be pretty confusing.

Anyway, the market have already settled on QR codes and AFAICT, the market did the right thing :-)

Well, an option would be to do "A better QR" but ISODEP doesn't answer that question, you primarily need the web security context.

Cards <<>> Phones

[cyberphone]

@anssiko @kenchris It might be worth mentioning the #1 application for "A better QR", right?

If you use a phone as a "token" which is extremely popular you can unfortunately be "phished" by trivial URL-tricks since there is no secure connection between the phone and the Web page asking for authentication. With a scheme that provide the Web security context, phishing i thwarted and that without needing to talk in the other direction (this is still done OOB using HTTP).

It would also cover secure payments on the Web!

And potentially be much more convenient than QR since an "App" (which is a core part of the plot), is launched automatically.

[zoltan]

wrong @zoltan ... you've ment @zolkis. unsubbing.

[Liryna]

This is where it gets difficult. The majority of valid use cases would build on using a mobile phone to approach a PC Web page.

I do not really agree here. Even if it is one of the possible use cases. There are a lot of more possibilities by using contactless card that using a phone. Contactless cards are used everywhere for a lot of purpose (banking, identification, storing data (secure or not), certificates,....) Giving web-nfc the possibilities to send ISO commands to the iso compliant cards will really unleash the possibilities.

From my point of view, the issue here would the usage of the iso compliant hardware and how it is used.

@anssiko I am really subscribed to the group as "Adrien JUND"

[cyberphone]

@Liryna Let me put it like this: What I described ("A Better QR") , would in my world be another API than ISODEP, and also having another security model although they in theory could be the same.

QR is already in use by more than 500 Million Chinese users and the shops in Europe are gearing up for that. If QR wins, I doubt that NFC will get any built-in support in PCs at all. Currently NFC is only featured in pricier PCs AFAIK.

[Liryna]

@cyberphone Oh yes in this way I agree.

Currently NFC is only featured in pricier PCs AFAIK.

I would even add that this NFC readers are often not made to be used for external apps (proprietary protocols even if detected by pcsc).

@anssiko just for my knowledge, what is used on windows/linux by chrome to detect readers and cards ?

[anssiko]

just for my knowledge, what is used on windows/linux by chrome to detect readers and cards ?

@Liryna, can you be more specific with your question? If you're interested in implementation details, see https://crbug.com/520391. This repo is for specification discussions.

[Liryna]

Exactly what I was looking for @anssiko ! Thanks for the link ❤️

[cyberphone]

@anssiko @kenchris As a somewhat funny coincidence, the Swedish BankID was yesterday victim of a phishing attack which wouldn't be possible with "A Better QR". No, the banks won't pester you with requests for such solutions; they still believe their favorite consultant can fix that!

[cyberphone]

@Liryna As you know EMV-cards never did it on the Web. The primary reason for that is that the EMV standard presumes that cards are used together with a secure (usually certified) terminal. A web browser executing transiently downloaded code from an arbitrary site is not the same.

Apple and Google indeed use EMV in their respective mobile payment systems, including on the Web, but the latter is facilitated through dedicated browser interfaces talking to the wallets which both are native apps.

Related: http://webpki.org/papers/permissions.pdf

Therefore I believe what you are asking for is not likely to happen since it would require application specific code in the browser. In desktop browsers, Google, Mozilla and Microsoft have recently introduced a concept called "Native Messaging" allowing you to bind native code to the Web which can do essentially whatever you want. For mobile browsers, Android Intents is a way forward which is used by thousands of very different applications. Apple does (AFAIK) not permit other parties using NFC so iOS is not a problem :-)

Personally my biggest concern is support for NFC in standard PCs. There's no important application out there using NFC and Web NFC won't change that in its current incarnation.

[Liryna]

@cyberphone We are just looking for using ISO 7816 contactless cards. To be able to send ISO7816 APDU commands like on Android. They propose a simple API that is enough for this standard. https://developer.android.com/reference/android/nfc/tech/IsoDep.html

ISO7816 has to be seen as a way to communicate to devices like any other protocol of communication. People can do whatever they want with it and the purpose is limited to the type of device they have in front. If you restrain people from having access to ISODep but let them NFC, you will probably create a new type of NFC device that will handle non "standard" NFC command tagged as ISO7816 and converted to APDU commands by the card at least it is what I would do.

Personally my biggest concern is support for NFC in standard PCs. There's no important application out there using NFC and Web NFC won't change that in its current incarnation.

I also want it. But why not give access to ISO7816 since the web-NFC use it to communicate ? NFC is not secure, don't you want to give the choice to people to be able to have secure ISO7816 device ?

[cyberphone]

@Liryna I fully understand what you want to do. The problem is that ISODep support would require an _exception from the Web Security Model in order to be practical_. This is a decision for the browser vendors, I'm just an independent technologist interested in NFC technology.

OTOH, if you consider what a malicious site could do you will find that there is a bunch of potential security and privacy issues which at least I don't know how to cope with. That it works in the physical world is because you actually "see" the relying party (terminal, physical reader) which doesn't translate well to the Web with its billions of relying parties. Effectively, ISODep support presumes that the user becomes the security mediator which is a hard sell these days.

[Liryna]

@cyberphone I do not understand what is the security difference between giving access to NFC data and ISO device data ? NFC is ISO7816. That's why this issue exists. web-nfc is already giving access to the device by allowing to send NFCMessage.

That it works in the physical world is because you actually "see" the relying party (terminal, physical reader) which doesn't translate well to the Web with its billions of relying parties.

Android does not show the terminal, physical reader or whatever. You just get a notification when a card is near and you can send command like here NFC gives the ability to send NFCMessage.

[zolkis]

Android does not show the terminal, physical reader or whatever. You just get a notification when a card is near and you can send command like here NFC gives the ability to send NFCMessage.

The problem - as Anders said - is that it's web sites that get the notifications and can run scripts using this API to start a transaction and transfer arbitrary data, not unlike a "remote SPI" interface. It is one thing that's a large exploit surface, but it's an even bigger problem that this attack surface is exposed to web pages, which in turn are also a large attack surface, and browsers have peculiar security model to deal with it, which might not be well suited in this case. In the best case I see this feature as being always behind the 'experimental' flag in a browser, which would restrict general usability. So Anders is right, and we need to do a more thorough analysis on whether and how could we expose this - but for now we need to focus on landing the current version.

[cyberphone]

NFC is ISO7816. That's why this issue exists. web-nfc is already giving access to the device by allowing to send NFCMessage

@Liryna To be perfectly honest I actually do not understand how the current scheme can be more secure than ISODep since the browser doesn't (AFAICT...), have any insights in the applications using NDEF. That is, the latter could indeed be arbitrarily sensitive. Maybe the authors could shed some light on this?

Anyway, the numerous problems in this space is also why I'm advocating a dedicated, locked-down, write-only Web-NFC variant, intended as a direct replacement for inconvenient and security-broken QR codes.

[zolkis]

NDEF with exception of opaque record types could be validated. Android does just basic validation, so implementations need to take care of that. Even with opaque records NDEF frame is required.

In turn, with ISODep etc we open a point-blank Pandora box and let it be used. However, if the user agrees... there are also other powerful features as well.

I'm advocating a dedicated, locked-down, write-only Web-NFC variant

That sounds good, please create an issue/feature request with use case and proposal. Could you elaborate on the locked-down part? Need to understand how different/stricter would it be from the current API. Also, whether it fits the charter.

[serianox]

For reference since it was mentioned somewhere in the thread, the specification result of the work started jointly within W3C and Global Platform [Web API For Accessing Secure Element].

This specification goes much further than Web NFC as it allows a trusted web page to communicate to any ISO compliant Secure Element, including (e)UICC, (e)SE and ISO contactless. On the other hand, it is limited only to Secure Element that communicate through APDU, i.e. no LLCP or HCE.

The security model is based on:

• explicit user consent,
• web application loaded through HTTPS,
• Access Control List on the secure element authorizing access to specific applications on the Secure Element from specific Web Origin.

[alexshalamov]

@romandev Are you aware of any discussions within Web Payments WG that are related to contactless payments or payment bootstrapping using NFC technologies? Would be great to get some pointers, as it might provide valuable information for WebNFC feature prioritization e.g., whether ISODep is required.

[Astriel]

Any update on this one ? Would love to be able to read the content of my travel card based on IsoDep.

[taralx]

I also really want this, but the core functionality still isn't launched, so I don't think we'll see progress on this until after that.

[Astriel]

I know this is already doable through Android, I've tested the metroroid app and I can have access to my last 6 travels by public transportation. Making this done through a website could make things easier rather than having to code a whole Android App just for that part :D

[hmiguel]

I know this is already doable through Android, I've tested the metroroid app and I can have access to my last 6 travels by public transportation. Making this done through a website could make things easier rather than having to code a whole Android App just for that part :D

+1 for this one.

[zolkis]

Developers are needed and welcome to work on these features. FWIW, we have drafts for extending the spec, if it comes to that.

[pawisoon]

Hi, is there any update on supporting this in WebNFC?

[robertarnesson]

2024 - any updates?