Fries, Steffen <[email protected]> wrote: > Currently we have different types of assertions defined (https://www.ietf.org/archive/id/draft-ietf-anima-rfc8366bis-12.html#name-yang-module): > - logged > - verified > - proximity > - agent-proximity
Yes.
> Logged and verified relates to actions which can be performed on the
> MASA side related to ownership verification, while proximity and
> agent-proximity provide information about the onboarding situation n
> the deployment domain.
Nonce-less vouchers would be logged, for instance.
> I was wondering if we address different assertions in one value based
> on the following use case:
> * A pledge (product) is sold via a distributor. The MASA has no
> information about the final customer.
> * If the pledge is onboarded, it creates a Voucher-request asking for
> a proximity assertion
> * The registrar provides the registrar voucher request including the
> pledge voucher request to the MASA
> * Based on the contained information, the MASA can verify proximity,
> but still may not know the customer (domain).
> * The MASA could react with the assertion "proximity". But given that
> the MASA has no information about the end customer it may also react
> with "logged"
That's correct.
I would always go for proximity if there is a voucher-request.
> With this, are we addressing two different statements in one
> enumeration? Or did I misinterpret the enum?
It may well be that in the ~10 years since we started, that the concepts have
drifted. Probably worth a re-think after a few years of real deployment.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
