Federation part 1

[OR13]

This issue tracks initial work to be completed regarding profiling of COSE to support federation for SCITT.

Some initial topics that still need to be addressed:

• How do transparency services discovery each other?
• How do they know if their policies are compatible?
• How do they know if they support the same issuers?
• How do they know if they support the same artifact types?
• How is issuer privacy impacted by federation?

[johnandersen777]

What are folks thoughts on making entry IDs hashes of claims? This would make it easy to manage state because claims and receipts are content addressable. The side effect is one can no longer register the same claim twice under a different entry ID. I wasn't able to find if the SCITT arch doc explicitly defined expected behavior there.

Example of what this might look like within the SCITT API Emulator: https://github.com/scitt-community/scitt-api-emulator/commit/9c54f9c542f042954e4d02b291ea4856327223be

127.0.0.1 - - [17/Oct/2023 18:08:08] "POST /entries HTTP/1.1" 201 -
127.0.0.1 - - [17/Oct/2023 18:08:08] "GET /entries/sha384:76303a87c3ff728578d1e941ec4422193367e31fd37ab178257536cba79724d6411c457cd3c47654975dc924ff023666/receipt HTTP/1.1" 200 -

[aj-stein-nist]

In your original comment, you mentioned a default hash algorithm and implementation.

The side effect is one can no longer register the same claim twice under a different entry ID.

Does this goes for entries under different hash algorithms and implementations, are those count as "the same" one entry ID?

[johnandersen777]

At least as I was playing with it in that emulator pull request it the hash algorithm used you be part of the entry ID (similar to container image format reference by sha256 format). It the entry hash algorithm could also be part of the service parameters. If log A and log B had different entry id hash algorithms federation would involve an index or mapping so that federation mechanics don't end up re-inserting a claim which already exists Example: Log A federates Claim A1 to Log B. Log B inserts claim A1 as B1, federates event to Log A which inserts claims as A2. If entries were content addressable it would be fast to determine and A2 is in fact A1 and does not need to be re-inserted. If they aren't the same then a mapping transmitted with the federation event would include the known entry IDs within each log or something.

[johnandersen777]

Related SCRAPI section: https://github.com/ietf-scitt/draft-birkholz-scitt-scrapi/blob/b0ee171a26d634a8f54eb46779dcd023ccdf2a63/draft-birkholz-scitt-scrapi.md#discovering-federation

Some options for Federation:

• https://www.w3.org/TR/activitypub/
  • Pros
  • Existing Adoption
  • Cons
  • Not sure if built with confidentiality as first thing in mind, not sure if this matters if the point is transparency
• WireFederation_0_0_4.pdf
  • Pros
  • IETF Adjacent?
  • Cons
  • Pre-v1
• https://github.com/decentralized-identity/decentralized-web-node
  • Pros
  • "Web5" ecosystem
  • Cons
  • They decided to go with a non-browser native approach, requires an extension
  • Heavily influenced by $$$
• https://openfl.readthedocs.io/en/latest/source/openfl/communication.html - https://github.com/securefederatedai/openfl/blob/develop/docs/overview.what_is_intel_federated_learning.rst
  • Pros
  • Feeds right into ML
  • Cons
  • TODO

It could be interesting for SCITT services to declare federation protocols they support via exported service parameters. Different instances my have different threat models and require different levels of assurance around CIA properties of federation protocols.

• https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/96#issuecomment-1817770016

federation:
- protocol: activitypub
  # Actor to follow to receive events for any statement (subject `*`)
  everything: allsubjects

• How do transparency services discover each other?

  • Enable multiple options for discovery
  • For services an instance federates with they can choose if they want to be exported as options
  • See notes later on privacy and subsequent federations policy

• How do they know if their policies are compatible?

  • At the IETF 118 hackathon we discussed labeled property graphs

• How do they know if they support the same issuers?

  • Policy graph traversal / policy analysis

• How do they know if they support the same artifact types?

  • Policy graph traversal / policy analysis

• How is issuer privacy impacted by federation?

  • Depends on selected federation protocol
  • Additional policy in place around federation
    • Levels of assurance in execution of subsequent federations policy
    • TEE, etc.
  • Depends on deployment context

[aj-stein-nist]

Thanks for a thorough summary, @pdxjohnny. On the IETF side I am not sure exchanging was intended to mean federation, but in the pub/sub context ROLIE way be partially or wholly useful.

https://datatracker.ietf.org/doc/rfc8322/

[SteveLasker]

Suggestion is to remove the federation section