Shots fired! Shots fired!
fsniper
I rechecked the current spec. It does not fully cover what a user agent can ask to the attestor ( "content binding" to be defined). So we can assume this attestation spec is defined at the attestor.
Of course this does not mean attestor can not have different profiles to attest for.
So your comment even though is possible, just not defined yet. Which we can - I believe - rightfully assume will be in the final spec or implementation.
In this context, calories not being same does not mean there are different kinds of calories.
However calorie source could mean how it's absorbed by your body may differ. So 100 calorie chocolate may provide your body 90 calories of energy, but 100 calorie lentil could provide your body 80calories worth of energy.
Block users all you want, but don't expect me to "attest my hardware and software" from a 3rd party. Let alone make this a standard and think about leaving the keys to parties which are probably "themselves" only.
How on earth the expectation can be giving authority to third parties to set my hardware and software to be validated so they attest to an arbitrary standard which I will never have control over?
See the current SSL certificate authorities mess. I have to pay to a third party to asure my clients that my server can securely communicate with them. Now they are doing this to clients with a more strict manner.
Consider this but triple the complexity and everything https://wiki.wxwidgets.org/images/1/1f/BinPjOptions.PNG
For now spec calls "holdbacks", which are designed for this purpose. Attestors will fail randomly for a set percentage of the requests so this can't be used as a whitelist. Surely this "holdbacks" will either be not implemented or dropped in no time by attestors.