Created: `$= dv.el('span', dv.current().file.ctime.toLocaleString(DateTime.DATETIME_SHORT))` Last Modified: `$= dv.el('span', dv.current().file.mtime.toLocaleString(DateTime.DATETIME_SHORT))` #ProductToken #AccessControl When leveraging a blockchain for the tokenization of real world assets there is almost always the need for off-chain metadata.  In many of my previous posts I’ve used the example of product tokens where on-chain we simply have a token ID and a URI that points to where the metadata is stored.  If we are clever we can have the URI contain a hash of the metadata so at a later point in time we can prove the data hasn’t changed.  If we are really clever we can have the URI be a Content Identifier like a CID in IPFS and we can continuously gather proofs that the off-chain metadata is available (no one is really worrying about this yet, but they should be…).  In the near term we need to consider that token metadata will be stored in a verity of off-chain locations, some using IPFS and Filecoin, some using traditional SQL databases, some using newer flavors of data units such as the OpenDSU in place for PharmaLedger.  Over time these may congeal, but there will always be several… So the question arises of how to manage access to the off-chain data?  The knee jerk approach would be to establish some sort of Role Based Access Control (RBAC) system that can determine who is allowed to see what data - but when we think about these data stores being all over the place and the level of standardization that would be needed to define roles and maintain the whitelist of accounts mapped to the RBAC this quickly becomes infeasible.  This approach would lead to centralizing the data and establishing a gate keeper to determine who can have access to what… which is the exact thing we are trying to avoid. It’s better to look at what all of these data stores have in common - that is the token ID.  To be more precise it is the Network:ContractAddress:TokenID paring that is exactly needed to locate a set of metadata that pertains to a given token.  Then to determine who should have access to it it’s simply a function of determining who controls the wallet(s) that the token is (or has been in).  As discussed in _this post_ we are leaning towards a model where there can be multiple claims on a token (I.e., ownership, custody, regulatory seizure, etc) so rather than just saying “the wallet that owns a token” should have access, we say “the wallet that has a claim on a token” should have access.  This is a form of token gating similar to what the Sign-in With Ethereum team is working on. One important with TCDA.  We don’t want to restrict access to metadata to only the current claim holders on a product token, we want to extend that access to anyone who has ever held a claim.  This is what will let a manufacturer of a product token see when someone downstream in the supply chain adds data to their product and is the only way that a full record of all the metadata can be generated by multiple participants in the supply chain without consolidating all the data in one place.  So the statement we are trying to hold up is “Any wallet that currently holds, ho has held in the past, a claim on a product token should have access to view the off-chain metadata”. ![[TCDA_Graphic.png]] There is a second level of access control which is possible here if there is a subset of the metadata that is only intended to be viewed by a specific wallet address (say that of a regulator).  We want to make sure that metadata is part of the permanent record, but is not necessarily available to everyone who has a claim on it.  The solution here is rather straight forward, we can encrypt the metadata, or at least a subset of it.  If we know ahead of time who should have access to it, we can simply encrypt it with their public key (their blockchain address) or the account generating the metadata can encrypt it and later share the key as needed.  We can even go a step further here and require that a wallet requesting access to the metadata hold a verified credential that might be issued by the manufacturer or the regulator and therefore revokable.  This in a way is another form of whitelisting, but it might make sense when used for just a subset of data and it give more control back to the account posting the metadata in the first place. There are several assumptions that we make in this model, the primary one being that the metadata originator will keep the data available and will not change it (changing it would invalidate the on-chain hash so when it’s retrieved later it would look invalid, even if the change was valid).  Solutions within IPFS and OpenDSU do a good job of addressing this, but the TCDA for access control is missing.  Another assumption here is that we rely on the actors with access to token metadata to be somewhat honest - meaning that if I’m a mid-tier wholesaler I won’t try to aggregate token metadata from all of my suppliers and sell it to people outside of the supply chain.  The good news is that this could happen today, and for the most part doesn’t… Another complication here comes into play when we try to manage claims on tokens under privacy.  By the very nature of making claims private, it makes it difficult to use that claim as proof.  Further some approaches for private transactions make the token ID itself a bit fluid so being able to use that as a hard key to route access will be tricky.  But we are advancing quite rapidly in this space, so I’m confident these nuances can be handled. In the near term will will need some common tooling that can be leveraged to make TCDA work across a variety of off-chain data storage solutions and possibly across multiple blockchain networks (imagine what will happen when we bridge a product token from network A to network B but TCDA is only in place for network A)…