SCITT Virtual Interim Meeting - 12.06.2023
Agenda
Notes
Registration Policies
- Open Issues in the GitHub Issues: Tagged Registration Policy
- Henk: believes we need at least trust anchors.
- Jon: Arch Doc currently uses Registration policies as gatekeeping
entries. Believes we need to be more flexible, using identity
relationships
- Jon: There are two challenges from discussions in the past: Formally
specifying identities (e.g. DIDs). Registration policies covering
contextual aspects (and having a semantic understanding of the
payload itself).
- Capturing the registration policy, at the time a registration was
made
- Orie: The primary complication is the dependency between different
envelope formats. For example, if you are storing your policy in the
TS and you want to reflect the policy at which the transparent
statement was produced. You can include the policy in the
transparent statement. This can get complicated.
- You need to discover the keys for the issuers.
- Hannes: Can we simplify the design?
- Orie: Yes, we initially didn't have the policies in scope. We can
also just reference policies and later worry about the details.
- Yogesh: A bit of registration policy could be an implementation
issue. Just focus on validate the issuer - focus on what to do (with
verification of identities) rather than how to do it.
- Ray: I agree with Yogesh. The TS is acting like a proxy to what
would be the other side of a TLS connection.
- Roy: A product build with SCITT, the ledger portion includes the
identity providers youre going to evaluate. Need to know what the
policy bar is, before you accept the receipt. Anything we have a
receipt for, must have passed a policy, but what policy was
evaluated? Need to capture these.
- Henk: Everyone agrees that we need a list of public keys (=trust
anchor). How are these represented? Where to store it/ where to find
this information? How to find it (identifers)?
- Neal: Relying parties will have to make decisions. Try to simplify
as much as possible. I see Sigstore as a great example making simple
decisions. Just restricting statements to specific issuers ignores
situations where issuers are compromised. Using TUF to deal with
revocation and key rollover is a good, well-vetted approach, so TUF
could be considered a useful example of a registration policy.
- Yogesh: Entity X registers with TS and has 5 products. It can use
any key to sign the statement but it does not need to be a
registered key.
- Roy: The transport mechanism isn't that important.
- Ray: Compares it with Let's Encrypt and the domain verification it
provides.
- Charlie: Totally agree with Yogesh. If I know the party, I don't
need a bunch of verifications.
- Edoardo: I understand to keep it simple. Removing policies entirely
might remove some use cases.
- Charlie: My use case is a medical device that has software/hardware
and that there is a way to track the parts, ownership, etc. I would
like to spend more time on the payload, compared to the
infrastucture, suppliers, ownership, companies of origin. Things
I'll have to be concerned about whent the regulators show up.
- Ray: The payload is better done in schema.org. Maybe do what RATS
did with their verifier and we provide the mechanism for people to
use and not to detail how exactly it is done.
- Roy: The definition of SBOMs, etc. is done in other groups, outside
the IETF. The difficult with RATS is: how do you know when things
have changed?
- Ray: Please explain us how this works.
- Charlie: We haven't spent much time on how to use the SBOMs
- Hannes asks Roy to start a discussion about this topic on the
mailing list.
Hackathon
Voting Topic