# Reputation-Based Trust Approaches in Named Data Networking
## 5 Discussion
### Open Issues & Challenges  
Based on the aforementioned merits of reputation-based schemes, we argue that all the above directions need to be further investigated. Different design option combinations, which result to different performance trade-offs, have to be thoroughly explored and NDN performance needs be quantified.  
For example, reputation values can be tied to each content object. This is a fine-grained approach, but introduces high overhead as the number of different ratings that would have to be stored, computed and disseminated is proportionate to the number of content objects. Furthermore, no reasoning can be made about a producer's future content. Reputation values can also be mapped to producers, performing some form of rating aggregation (based on the ratings on each producer's content objects). This enables pro-active reasoning about the trustworthiness of a producer's future content, but may also harm legit new objects (fake positives). Furthermore, there are technical challenges, for example how to extract the producer from a Data packet. A solution is to aggregate all ratings to the previous level of the naming hierarchy, the other one being to rate the associated certificate's identity. This method exploits the NDN's certificate format, which requires certificates names to adhere to the format /<SubjectName>/KEY/[KeyId]/[IssuerId]/[Version]. What is important, is the fact that a certificate name starts with the identity to which a public key is bound, that is, the namespace under which it can sign Data packets. Therefore, trust ratings can be provided for each associated identity to assess the trustworthiness of its certificates and published content.  
Another open issue is how to authenticate the ratings. As NDN is designed with consumer-oriented privacy in mind, the Interest packets are not signed by default. An option is to providing the ratings using signed Interests, but, in this case, consumer privacy would be violated and routers would be made vulnerable to flooding attacks by signed Interests (which would be much more effective than typical Interests, due to the signature verification overhead). The other option is to design a pull-based protocol, so that the ratings are provided by Data packets which are always signed. But this would dictate that consumers cannot immediately provide a rating for each Data packet they receive, instead they have to wait for their ratings to be periodically requested and collected (the higher the frequency, the larger the overhead).  
Furthermore, a reputation-based system relies on consumer feedback. Deployable solutions need to ensure that this feedback is being provided. A transaction-based system design can hard-code this in protocol design, for example when a signature cannot be verified, the protocol is going to provide negative feedback. Clearly, this is an option for mitigating attacks. On the other hand, an opinion-based system that focuses on data quality assessment, may require end-user participation as well as proof that a transaction has taken place. This would also which necessitates an mechanism for such a proof, as well as an incentives mechanism. Blockchain-based solutions can be used in this case, such as Proof-of-Prestige [47] which forms a reward system for unverifiable tasks.