Re: [Rats] Same claim in Evidence and Results (was Re: Second attempt at early allocation of CWT Labels (PR #152))

["Smith, Ned" <[e-mail]>]

Eric,
From Mike Bursell’s book – “Trust in computer systems and the cloud”, its suggested that trust can be represented in a 2Xn table where the right column lists the trust assumptions of the trustee and the left column trust assumptions of the trustor. If the assumptions map / are corelated / from trustor to trustee then trust exists. In RATS arch context an Attester is a trustor and Verifier is a trustee. Or Verifier is trustor and RP is trustee. In a background check model, an Attester is a trustor and the RP is a trustee, but only if a Verifier agrees. In general, the Attester • RP trust relationship is the primary objective behind attestation. The other interactions support aspects of the trust ingredients.

The trust relationship has the following ingredients:
Context(s), Time-specifics, Action(s), Expectation(s) and Assurance(s).

Claims are just the building blocks for making statements in each of the 5 ingredients.

Using Mike Bursell’s model, the ingredients are what defines “scope” in the thread below.

The other RATS roles (Endorser, RVP, Verifier, Verifier Owner, RP Owner) qualify some aspect of the table ingredients. But ultimately, the RP needs to do the mapping exercise: Attester • RP in order to establish trust. That implies the table is fleshed out. Maybe some reduction of claims is applied to change the level of abstraction, granularity etc… but that doesn’t mean the context of who asserted what is filtered / removed.

From a standardization perspective, having commonly understood building block claims is a bit like agreeing on the words we use to make sentences. But if a claim could be used in more than one ingredient in the table above, then knowing which ingredient the sentence describes is important context. We wouldn’t expect to deduce the ingredient statement simply by looking at the claim any more than we should expect to deduce the meaning of a multi-word sentence simply by looking at one word.

The environment to which evidence measurements belong is an important context about the Attester. The context of which Attesting Env. Collects claims about which Target Env. Establishes an expectation that the Attester didn’t lie about its measurements. A RVP asserting claims that match evidence claims establishes assurance that the claims are correct. Etc…

The RATS RP role is essentially only half of a role because it doesn’t define application / use case specific elements; only attestation specific. That means some of the table ingredients (such as actions and possibly expectations) are out of scope for RATS. But RATS work creates a place to fill-in-the-blank for the parts that are app specific.

From: RATS <[e-mail]> on behalf of "Eric Voit (evoit)" <evoit=[e-mail]>
Date: Tuesday, February 22, 2022 at 1:02 PM
To: "Smith, Ned" <[e-mail]>, Laurence Lundblade <[e-mail]>, Henk Berkholz <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Rats] Same claim in Evidence and Results (was Re: Second attempt at early allocation of CWT Labels (PR #152))


Thanks Ned for your last two emails.



I have been trying to track the overall conversation across forks.   I see your comments/questions on the UEID thread as coupled to the thoughts below.  (I.e., "Since scope is defined by the entity that asserts the claims, it would be better to describe claims using terminology that doesn’t assume scope IMHO.")



I agree with this sentiment.  For me this set of threads keeps coming back to establishing claim context to the Relying Party.   If the Policy for Attestation Results doesn't simply and unambiguously know the identity/source of a claim, the architectural role making the claim, and the freshness, then we are wasting our time here.



So we need to minimize Relying Party policy language ambiguity.



For me, I like separating the names of claims which might come from different architectural roles.   Things are easier for Policy programming on the Relying Party this way.

And we won't suddenly find a claim from a Verifier which now can also come from an Attester.



There are alternatives to doing this with namespaces.  But we no proposals going down this path yet.

Eric



> -----Original Message-----

> From: RATS <[e-mail]> On Behalf Of Smith, Ned

> Sent: Tuesday, February 22, 2022 3:31 PM

> To: Laurence Lundblade <[e-mail]>; Henk Birkholz

> <[e-mail]>

> Cc: [e-mail]

> Subject: Re: [Rats] Same claim in Evidence and Results (was Re: Second attempt

> at early allocation of CWT Labels (PR #152))

>

> I asked for clarification about what attestation roles' perspectives were

> assumed when describing the various claims. This was because there is language

> that suggests Endorser / RVP roles were considered. There is language that

> suggests RP, Verifier and Attester roles are considered too. But it isn't clear that

> all roles are considered for all claims.

>

> I suggested that if the goal was not to consider all roles for all claims, that the

> claims be described based on a least common denominator assumption. That is,

> only wording that is true for all roles would be included. It is a bit of a trick

> question in that you have to consider all roles in order to know what attributes

> will be common. It also means anything that is specific to a role or nuanced

> would not be included so as to avoid special case descriptions.

>

> That means, terminology that is aimed at manufacturers, relying party, verifier,

> attester should be removed or clearly identified as informative. My guess is the

> result will be that the CDDL most closely captures normative expression and

> most everything else is informative.

>

> On 2/22/22, 11:51 AM, "Laurence Lundblade" <[e-mail]<mailto:[e-mail]>> wrote:

>

>     Absolutely do not want to expand the EAT doc to cover Endorsement and

> Reference Values in any way, but maybe another draft might make use of some

> stuff that is in EAT.

>

>     Ned suggested it, not me. :-)

>

>     LL

>

>

>     > On Feb 22, 2022, at 11:19 AM, Henk Birkholz

> <[e-mail]<mailto:[e-mail]>> wrote:

>     >

>     > You are kidding, right?

>     >

>     > On 22.02.22 20:12, Smith, Ned wrote:

>     >> Maybe that’s a good idea. Maybe it’s not. Not sure yet. :-)

>

>

> _______________________________________________

> RATS mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/rats