I don't get the art focus.
They can be a degree, a concert ticket, a driving license, a permission to a API service, equity to a company.
I don't get the art focus.
They can be a degree, a concert ticket, a driving license, a permission to a API service, equity to a company.
You can code a non-tradable NFT no problem.
Tradable NFTs are just the hype right now.
WTF does that even mean?
Do people remember what a blockchain even is, at this point?
A blockchain is a chain of transactions. You take away the transactions, and its not a blockchain anymore. Unless we really stretch the definition of a "transaction" or blockchain......
Cryptocurrency has lost the plot. People are talking about blockchains, that don't have mining, or transactions now apparently.
I was just pointing out how it can be done or how it might make sense, if you needed it for something where blockchain did actually make sense, but in the case of drivers licenses, I don't think it does.
Also, it doesn't necessarily have to be a single central authority adding transactions; a whole bunch of DMVs could very well post to the same blockchain and only trust the validity of ID tokens issued by one another (i.e. with some out-of-band method to associate keys with actual DMVs, much like PGP's "web of trust" concept). This could even pave the way to things like drivers' licenses being partially or fully decentralized, with independent issuing authorities trusting one another based on some external certification process (e.g. "the California DMV has audited Foo Bar Licensing, Inc. and verified that it issues licenses in compliance with the California Vehicle Code, and therefore recognizes FBL-issued licenses as valid").
Allow me to use your example if I want to explain the main advantage of Blockchain derivative technology. Most of people seem to mix up Blockchain and Bitcoin, and think that Blockchain is equivalent to Bitcoin.
> some external certification process
Or just skip the extra complexity and have it all handled by a central authority?
Yes, you can use a blockchain to implement it how you describe, but I still don't buy that it has any real advantages. Also, who would run the blockchain?
> a whole bunch of DMVs could very well post to the same blockchain and only trust the validity of ID tokens issued by one another
> with independent issuing authorities trusting one another
If they are the only ones who can issue tokens and they have to trust each other anyway, why does it need to be a blockchain anyway instead of some shared database? Or if you want to keep it distributed, a peer-to-peer distributed hash table or other peer-to-peer database of ID tokens that only the DMV's have write access to. No need for a blockchain.
> if you have a California driver's license and I (as a Nevadan) want to verify its validity
If all the states share a blockchain, then they could just as easily share a database and web interface that you can look up. If they don't share a blockchain, then I don't see how its any different from each having their own system. I mean, even if its a blockchain, how well it works is then up to each state and if there's a centrally mandated blockchain they should be using, then there could also be a centrally mandated database they could be using. It just moves the goal posts around, it doen't in itself solve it. The person checking (bar staff in your example) still need a website or app that they can input the data to derive the hash (as not to leak personal data) and check the hash against the blockchain, this could just as easily work against a central or state database and how well it works, in either case, is still very much dependent on each state.
It seems overly complicated to build this on or as a blockchain.
Then every agency would have to trust some central authority. Maybe doable for interstate queries (with the associated federal bloat, but that's hardly anything new), but once you go international that becomes a lot harder.
> Also, who would run the blockchain?
Who runs Bitcoin? Ethereum? Cardano? Dogecoin?
> If they are the only ones who can issue tokens and they have to trust each other anyway, why does it need to be a blockchain anyway instead of some shared database?
The amount of trust required for "I'm reasonably sure this agency issued this driver's license" is far lower than the trust required for "I'm okay with this agency having control over my agency's records".
> Or if you want to keep it distributed, a peer-to-peer distributed hash table or other peer-to-peer database of ID tokens that only the DMV's have write access to.
A.k.a. a blockchain. You don't even need to restrict write access; DMVs can readily ignore transactions by non-DMV entities.
> If all the states share a blockchain, then they could just as easily share a database and web interface that you can look up.
That ain't anywhere near as easy, both politically and technically. This is already something they struggle do to, and distributed ledgers make that struggle entirely unnecessary.
> if there's a centrally mandated blockchain they should be using
There wouldn't need to be a mandate. States are perfectly capable of making agreements with one another, and could opt into a public blockchain at their leisure. CCW reciprocity is a good example of this; states have on their own come to recognize concealed carry permits issued by other states, and a blockchain would be a natural fit for recording and authenticating said permits under that dynamic.
Even assuming the need for a mandate, it's a hell of a lot easier for the federal government to say "hey, all states need to use this public blockchain per this standard" than for the federal government to roll out a whole central database that's scalable enough to handle queries nationwide and say "hey, all states need to use this central database".
> The person checking (bar staff in your example) still need a website or app that they can input the data to derive the hash (as not to leak personal data) and check the hash against the blockchain, this could just as easily work against a central or state database
Yes, and that would - again - require either:
1. a central authority that each state's agency trusts to be the record of truth, or:
2. 50 separate databases with 50 separate APIs.
A public blockchain absolves the need for either; agencies can maintain their licensing data autonomously (and, for that matter, data pertaining to those licenses; e.g. recording traffic citations, additional endorsements, etc., even for licenses issued by other agencies) without needing to deal with all that infrastructure.
They already have to do that! The central authority has to issue the licenses in the first place. Unless you are suggesting some absurd, decentralized driver's license issuing? Even that is begging the question though, as there has to be some centralized process to decide who is allowed to issue driver's licenses.
> A.k.a. a blockchain. You don't even need to restrict write access; DMVs can readily ignore transactions by non-DMV entities.
Alright, you are really stretching the definition of blockchain. Like, lets say someone just mirrors the database. So there is a web interface, and someone else copied the whole thing down.
Does that now count as a "blockchain" lol? Having more that 1 copies, of a mysql database, is a blockchain now?
The US federal government is not at all involved in issuing state drivers' licenses, last I checked. Nor is some international agency at all involved in issuing drivers' licenses within any given country. That's what I'm getting at with "central authority" - specifically, a central authority external to the issuer and/or validator.
> Like, lets say someone just mirrors the database. So there is a web interface, and someone else copied the whole thing down.
Is that person going to continually copy it down? What about data from other agencies? How many people are going to be using your web interface?
What I'm getting at there is that this all seems like an awful lot of work compared to just, you know, including some data in a transaction on any ol' existing blockchain (even Bitcoin or Dogecoin or what have you is good enough for this, let alone something that actually supports NFTs like Ethereum or Cardano) and using any ol' blockchain client/explorer to lookup whatever transaction got printed on the ID card.
> What I'm getting at there is that this all seems like an awful lot of work compared
They are literally the same thing.
The definition of what a "Blockchain" is has stretched so much, that having 1 mirror of a database would now fit people's definition of what a Blockchain is.
Once we get rid of proof of work, and transactions, the only thing we are left with is "a database which has mirrors".
Neither of which I suggested getting rid of above (though to be clear, proof of stake and proof of burn both exist). Transactions are especially handy when you move beyond merely recording the drivers' licenses themselves and actually start recording things like, say, traffic tickets or new endorsements or what have you - and that handiness is significantly improved further when agencies are sharing a single public blockchain instead of trying to maintain umpteen different internal databases explicitly tracking each other.
Even taking your assumption that a blockchain and a database mirror are "literally the same thing", you're still missing the key difference: that the former gives you the benefits of the latter (or at least the ones relevant to this context) with significantly less effort. It's similar in comparison to, say, using IPFS v. mirroring an FTP server; yes, you can create a bunch of FTP mirrors, and reinvent a poorly-specified ad-hoc substitute for half of IPFS, but it'd be a heck of a lot easier and more robust to... just use IPFS.
The blockchain space is just starting out and people try new things. But many can only see the crypto currency use-case.
transactions change the state of the database. they aren't limited to trading-related transactions.
Just think about all cases of fake liceses? This could be verified rather easily with an NFT while faking it would be quite hard.
Since drivers licenses are linked to individuals, and cannot be traded, the traffic cop that's checking your license will need to compare it to your government issued ID. Then they look it up to see that its valid and linked to you as a person.
How is doing this as an NFT (or other blockchain thing) any better than having a government database they look up?
This is a big problem I have with most blockchain tech: yes, it can be built on a blockchain, but it doesn't need it and alternatives tend to be simpler and cheaper.
I'm overall pro cryptocurrency and blockchain, but if we want people to still take it seriously in twenty years time, we need the use cases to actually make sense. I don't see how NFT's make sense here, unless I'm missing something.
But having a globally available, decentralized, and transparent database for some of these "certificats" could be a good thing.
If it's an out-of-state (or worse: international) ID, then the traffic cop (or, speaking from experience, some clerical worker back at the station) would need to deal with some bespoke interface for some external government database - and thus be at the mercy of that external agency. Such interfaces do exist, but they're clunky and antiquated, and it's pretty difficult to get authorization to connect to it. Even for intrastate lookups, a centralized database entails a bunch of infrastructure that's rarely publicly-accessible.
With a (public) blockchain, this becomes a heck of a lot easier and more accessible, since anyone from anywhere can query it with a common and publicly-known interface. Likewise, any agency can post to it without necessarily needing prior authorization and without needing to be at the mercy of other agencies; while there's obviously still a need for agencies to communicate with one another to exchange public keys (and therefore recognize/trust each others' blockchain transactions), that's much less complicated than coordinating a bunch of ad-hoc API connections.
It would more likely be something rolled out by the agency itself. That somebody could accordingly be the agency (preferably just a rebadged and customized version of some FOSS application) and "some reason" would be "not having to duplicate a bunch of effort just to maintain an ID database".
> using a more complex system that they have less control over
I think you're underestimating the complexity of building 50 separate databases and the connections between them, as well as overestimating the control an agency would have over 49 of those databases. And that's just for interstate lookups, never mind international.
Point being: in the grand scheme of things, a blockchain-based approach would be far simpler and offer more control.
I don't know police agencies well at all, but I suspect that if a local police force was deciding between "use the state system" and "use some frontend we built ourselves or needed to license ourselves and has no reason to have any tech support", they are going to choose "use the state system".
Or heck, just use a federal system.
Only if you assume that every country will actually collaborate and use the same blockchain. Much more likely, in my opinion, is that each country will have its own incompatible blockchain and the end result won't be any different than what you described.
I mean, I get what you're saying and its more likely that an international standard would come into use if no individual country has control over it, but I still think its unlikely.