Please note, this PR does not actually add any new feature to the project. It does however help clarify how existing features can solve a users problem.

Does this suit your need @Simonl9l, @joegoldman2. Also curious if you have any thoughts @iamcarbon and @aseigler.

I've left it out of this PR, but I am interested in writing a FileSystemBlobRepository that sources the mds.jwt blob from the file system instead of multiple json files that the current FileSystemRepository and a "uncached" service that sits on top of it.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.34%. Comparing base (c0cdfc5) to head (7d8d117).
⚠️ Report is 1 commits behind head on main.

@@ Coverage Diff @@
## main #620 +/- ##
==========================================
+ Coverage 77.55% 78.34% +0.79% 
==========================================
 Files 98 98 
 Lines 2539 2540 +1 
 Branches 422 422 
==========================================
+ Hits 1969 1990 +21 
+ Misses 460 440 -20 
 Partials 110 110 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Checking in again if this solves your previous issues @Simonl9l, @joegoldman2?

Checking in again if this solves your previous issues @Simonl9l, @joegoldman2?

@abergs we’re currently on a different path in this regard, and are no longer actively/currently using you package so defer to others.

thanks though for all you work on this package.

@abergs this new API is more user-friendly, thank you for that. However, there is still something I don't really like and understand. The service is still strongly coupled to the cache, so it's mandatory to register IMemoryCache + IDistributedCached. Any chance we can have a version of IMetadataService without any cache mechanism and propose the cache as an opt-in feature?

@joegoldman2 Thanks for your response.

The service is still strongly coupled to the cache

Yes, the CachedMetadataService is strongly coupled to asp.net's caches.

You could implement a non cached version easily with the help of the documentation in this PR. The reason I don't want to ship a uncached version in the nuget package - or even encourage it - is because it's a footgun:

1. You should really only use the MDS + Attestation if you understand why you have a need for it (e.g. you work in regulated spaces)
2. If you need those security guarantees from the MDS + Attestation, you'll likely don't want your service to fall over because of the mds rate limiting or not being available. The MDS service dictates that you should rely on your caches and will rate limit you.

It's just weird for me that the cache is at the service level and not at the store level (with a decorator for example).

@joegoldman2 When you say store level, you mean the repository?

Is there some naming changes we could consider to make this easer to understand?

@joegoldman2 When you say store level, you mean the repository?

Yes, the repository sorry.