EskoDijk
commented
1 month ago @stfries In the current design of the assertions, both aspects are combined into one.
- "logged" means that the onboarding action (i.e. each issued voucher) is just logged with minimal validation. E.g. only validate that the Pledge is a genuine device and write the domain claiming its ownership into the log.
- "proximity" means that proximity was verified and that the action is also logged like above.
- "verified" means ownership was positively verified in some way, which the Pledge wouldn't need to care about how, just that it has been done successfully. In this case it's not needed to state "proximity + verified" I think, because "verified" alone should be all the Pledge needs to make its decision to accept the Voucher!
So "proximity" looks like a weaker variant than "verified". For example if ownership is already validate through sales integration then the "agent-proximity" assertion would also not be used. "verified" includes also "logged" by definition, because the MASA would anyhow need to log the issued voucher. For tracability or to avoid issuing unlimited vouchers for the same device.
TBH I don't see a need to split the assertion into two parts. Or is there a specific reason to include the proximity information separately in the Voucher?
e.g., a proximity assertion together with the supply chain integration information may lead to enable additional functionality of the pledge
If the vendor has already "verified" the customer, and writes this in the Voucher , it means the Pledge can enable all its features that are intended for verified users. There should be no difference in functions if the Voucher would state "verified + proximity". If there are distinct features to be enabled for the target customer: vendor-specific fields with those features can be included in the Voucher and no need to use the assertion for that.
Maybe I miss something here but I think the intended design was a single assertion that spans the spectrum from "barely verified" to "fully verified" and everything in between. Any other feature selection can be placed in vendor-specific fields. See also the 8366bis text that says:
The MASA generated this voucher using the 'verified' assertion type, which should satisfy all pledges
RFC 8366bis (and originally RFC 8366) define assertions that are provided in the voucher as enum. For RFC8366bis, these assertions comprise:
The YANG module defines the assertions as statement from the MASA regarding how the owner was verified. This fits in general for verified and logged and describe the MASA "trust" into a potential customer domain. Proximity (and agent-proximity) seems rather an assertion that attests that the pledge has seen the correct registrar, which can be attested by the MASA. The current YANG description does not explicitly relate to the ownership verification or supply chain integration for this assertion.
The MASA may provide a proximity assertion by verifying the relation of the Registrar Certificate in the PVR and the Registrar Certificate related to the RVR. This may be independent from the supply chain and the MASA may provide this assertion independent, if he has a direct connection to the customer or no connection to the customer if the pledge was sold via a distributor.
This may lead to the discussion of having two different assertions, one focusing on the ownership related status or the trust between the customer and the MASA (currently "verified" and "logged") and the second one for the relation of Pledge and Registrar in the customer domain (currently "proximity" and agent-proximity").
If both assertions are evaluated they may lead to different pledge behavior (e.g., a proximity assertion together with the supply chain integration information may lead to enable additional functionality of the pledge). Currently I don't have a dedicated use case in mind and would expect the pledge is reaction in a similar way. But having semantically different information as distinct assertions could help addressing future scenarios.
The trust between customer and MASA may be established in different ways:
See also email discussion