Re: [Gen-art] Genart last call review of draft-ietf-rats-eat-21

[Ines Robles <[e-mail]>]

Many thanks Laurence for addressing my comments and for the providing
clarifications

I understand the provided motive to not imply the trust to be static.
Perhaps, one way to convey the potentially varying degree of trust
dependant on context can be achieved by replacing "wishes" (which is
usually attributed to human sentiments) and as well as changing "how much"
(which represents in my understanding a quantity value):

Thus, instead of:
"This claims set is used by a relying party, server or service to determine
how much it wishes to trust the entity."
how about?:
"This claims set is used by a relying party, server or service to determine
the applicable trust in the entity."

What do you think?

Thank you and Best Regards,

Ines.

On Thu, Aug 10, 2023 at 10:03 PM lgl securitytheory.com <
[e-mail]> wrote:

> The PR to address these is here:
> https://github.com/ietf-rats-wg/eat/pull/403
>
> Comments below.
>
>
> > On Aug 9, 2023, at 4:47 PM, Ines Robles via Datatracker <
> [e-mail]> wrote:
> >
> > Reviewer: Ines Robles
> > Review result: Ready with Nits
> >
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed
> > by the IESG for the IETF Chair.  Please treat these comments just
> > like any other last call comments.
> >
> > For more information, please see the FAQ at
> >
> > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
> >
> > Document: draft-ietf-rats-eat-21
> > Reviewer: Ines Robles
> > Review Date: 2023-08-09
> > IETF LC End Date: 2023-08-09
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> >
> > This document describes Entity Attestation Token (EAT) that provides an
> > attested claims set that describes state and characteristics of an
> entity. This
> > claims set is used by a relying party, server, or service to assess the
> > trustworthiness of the entity. EAT is constructed as a framework for
> defining
> > specific attestation tokens for specific use cases.
> >
> > The document is well documented, with good set of references. No major
> issues
> > found, minor nits found as specified below.
> >
> > Major Issues: None
> >
> > Minor Issues: None
> >
> > Nits:
> >
> > - Abstract: What about "...service to determine how much it wishes to
> trust the
> > entity." --> "...service to assess the trustworthiness of the entity." ?
>
> I prefer it as is, but am open to the change if there is consensus.
>
> I prefer it as is because it I think the existing wording leaves room for
> the context of the trust.  To me your proposed wording seems like trust is
> determined once for all use cases. I think one might trust the same entity
> in one context, but not in another. For example, one context might be for
> transaction in dollars and another might be for authentication to access
> governmental data. I don’t think trust or trustworthiness is universal
> (even though lots of engineers, marketing people and such do use the word
> that way).
>
>
> >
> > - Section 4.1.17: Maybe "failure, fail to run, ..." --> "failure, fail
> to run,
> > among others." ?
>
> Changed to "success, failure, fail to run, and absence” because there are
> only four options.
>
>
> >
> > - In Section 4.2.14 "(DLOAs))" --> (DLOAs), the same for (Section
> 4.2.16)) in
> > Section 6.2.12
>
> Fixed.
>
>
> >
> > - Section 4.3.3 and Section 7.3.1. "TBD(BUNDLE-Untagged-Message)" -->
> > TBD602(BUNDLE-Untagged-Message) ? (To be aligned with IANA Section)
>
> Fixed.
>
> >
> > - Section 6.2.12: "This document requires an EAT receiver must accept all
> > claims it does not understand." are there specific security
> consideration to
> > follow in this case not mentioned in section 9.1?
>
> Reworded to "This document requires an EAT receiver must accept tokens
> with claims it does not understand” as the
> existing sentence really didn’t say the right thing.
>
> I don’t think there are security concerns here.
>
>
> >
> > - Section 6.3: It would be nice to have a caption for Table 2. (Same for
> rest
> > of the tables)
>
> Fixed.
>
> >
> > - Section 7.3.1: "one place that that a CBOR token" --> "one place where
> a CBOR
> > token" ?
>
> Fixed.
>
>
> >
> > - Appendix C.1: "EAT doesn't define a an device implementation and DevID
> does."
> > --> "EAT doesn't define a device implementation, but DevID does." ?
>
> Fixed.
>
>
> >
> > Thanks for this document,
>
>
> Thank you for reviewing. It’s a long document and I know it takes a lot of
> work.
>
> LL
>
>
> >
> > Ines.
> >
> >
>
>