[Anima] Re: Question regarding use of assertions in vouchers in RFC8366bis

[Michael Richardson <[e-mail]>]

Fries, Steffen <steffen.fries=[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide