Re: [web-nfc] Fix external type validation algorithm (#511)

@zolkis Does it make sense to review in a PR? That makes it easier to add in-line comments, and might save some extra commits :)

Recall that #350 came up because, at the time, there was a relationship between the document domain/origin, the registerable domain, and the NDEFRecord tag, and the issue I was trying to flag (with IPv6 and with URL Standard) was that there exist origins for which cannot be represented in NDEFRecords, leaving the security check of limiting the origin to only reading its tag in an awkward state, and needing to be nailed down. It looks like you cleaned all that up in #474 , which means much of #350 (all of it?) is obviated :)

As I understand it, that check is now fully removed, and reasonably so: Web NFC uses the external tags and domain names not as a security/ACL check, but simply as a way of ensuring unique registrations, much like an [ITU/ISO/IEC Object Identifier](https://en.wikipedia.org/wiki/Object_identifier), since the domain name system is similarly hierarchical and delegated.

As a result, I *think* that means you don't need to handle IPv6 anymore and your algorithm for processing the type can go back to processing the first `U+003A (':')` to determine the domain. If I'm understanding correctly, and the domain portion is only used for unique identification, then you do *not* want to allow [U-Labels/IDNs](https://www.icann.org/resources/pages/glossary-2014-02-04-en), but require A-Labels/LDH-Labels (I believe this is what was trying to be done with the reg-name syntax).

Thus your parsing/validating/encoding algorithm becomes something roughly like:
1. Find the first `:`
    * If none, error
1. Split the string on `:`
    * Set `domain` equal to everything up to but excluding `:`
    * Set `type` equal to everything after `:`
1. Validate `domain` is LDH-label
1. Validate `type` is within the allowed character space
1. (If encoding) Validate length

Now, you can shuffle these steps around in an order that makes sense. For example, implicit in this is an assumption that you've validated that the input is an [ASCII string](https://infra.spec.whatwg.org/#ascii-encode), which thus makes sure that the character length == byte length when ASCII encoded. That could be first, or that could be only part of encoding, I'm not sure what makes most sense for you.

Because you're not dealing with the document's origin/domain anymore, handling U-labels isn't necessary. Developers using WebNFC will be using explicit tags, so they shouldn't need to worry about things. A developer *shouldn't* just use document.domain to construct the tag, because the whole point of the tag space in NFC, is, as far as I can tell, to make it explicit the namespace of the thing you're writing.

@beaufortfrancois If I'm wrong/misunderstanding this, maybe you can set some time on my calendar to explain this for me. I really have little background in NFC here, I largely filed #350 because of the PSL dependency leading to weird specs (and the issues mentioned in https://github.com/sleevi/psl-problems), and I think #474 addressed the bulk :)

-- 
GitHub Notification of comment by sleevi
Please view or discuss this issue at https://github.com/w3c/web-nfc/issues/511#issuecomment-570620933 using your GitHub account

Received on Friday, 3 January 2020 16:21:28 UTC