I tried to find something definitive, but it would take more time than I have right now.
So to some degree this is assumptions, though generalized.
* Does the site know who the user is: No. That's the entire purpose here.
* Does the site know who the attestor is: Yes, they need to validate asymmetric crypto on the proof, so they need a list of public keys (which they can attach attestor identity to).
* Does the attestor know what kind of content I want to visit: They should not. With the JWT you can validate without telling the attestor which user's proof you validate. OTOH, if there's some "is this one revoked" type of API one could easily re-introduce such an information channel on accident.
* does the attestor know who the user is: Yes (or at least have some bits of information about you they are willing to attest to others. In practice assume it's Google/Apple/MS with information associated with your account, or your bank or ...)
* Does the user always know site/attestor: From a technical perspective yes. From a practical human one... doubtful.
--Googler, though far removed from this project, so no internal knowledge.
I think you are talking about colocation, which is slightly different than the `jj git push` `jj git fetch` type commands.
Colocation has its uses bit is a bit finicky. The push/pull compatibility works perfectly fine (with some caveats of github being broken that can be worked around).
Actual fips compliant (certified) gives you confidence in some basic competence of the solution.
Just fips compatible (i.e. picking algos that could be fips compliant) is generally neutral to negative.
I'm not 100% up to date, so that might have changed, but AEAD used to be easier if you don't follow fips than fips compatible. Still possible, but more foot guns due to regulatory lag in techniques.
Overall, IMO the other top-level comment of "only fips if you have pencil pusher benefit" applies.
Your pseudo XML seems quite broken, since the supposed git style doesn't close the parent at all.
But the git directory entry contains:
* a type (this one is quite limited, so I'm not sure how well that could be (ab)used
* a name
* a pointer to the content
Why do you think it has too many children? If we are talking direct descendents, I have seen way larger directories in file systems (git managed) than I've ever seen in an AST.
I don't think there's a limit in git. The structure might be a bit deep for git and thus some things might be unoptimized, but the shape is the same.
That black hole behavior is a result of corporate processes though.
Not a result of git.
Business continuity (no uncontrolled external dependencies) and corporate security teams wanting to be able to scan everything.
Also wanting to update everyone's dependencies when they backport something.
Once you got those requirements, most of the benefits of multi-repo / roundtripping over releases just don't hold anymore.
The entanglement can be stronger, but if teams build clean APIs it's no harder than removing it from a cluster of individual repositories.
That might be a pretty load bearing if though.
* Does the site know who the user is: No. That's the entire purpose here.
* Does the site know who the attestor is: Yes, they need to validate asymmetric crypto on the proof, so they need a list of public keys (which they can attach attestor identity to).
* Does the attestor know what kind of content I want to visit: They should not. With the JWT you can validate without telling the attestor which user's proof you validate. OTOH, if there's some "is this one revoked" type of API one could easily re-introduce such an information channel on accident.
* does the attestor know who the user is: Yes (or at least have some bits of information about you they are willing to attest to others. In practice assume it's Google/Apple/MS with information associated with your account, or your bank or ...)
* Does the user always know site/attestor: From a technical perspective yes. From a practical human one... doubtful.
--Googler, though far removed from this project, so no internal knowledge.