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

["Eric Voit (evoit)" <[e-mail]>]

 Hi Laurence,
 
> From: Laurence Lundblade, February 23, 2022 3:44 PM
> 
> On Feb 22, 2022, at 1:00 PM, Eric Voit (evoit) <mailto:[e-mail]> wrote:
> 
> <snip>
> 
> So we need to minimize Relying Party policy language ambiguity.
> 
> I don’t quite understand this comment. Maybe my last few paragraphs address
> this? Maybe my answer is that creating broad general unambiguous RP policy
> language is a rat hole we don’t want to address in the IETF?

Building an entire policy language is the IETF is not necessary.  But if we can agree to unambiguous object names, life is easier.

>  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.
> 
> Using string labels, would you want something like this?
> 
>    “evidence.location”
>    “results.location”
>    “evidence.ueid”
>    “results.ueid"
> 
> to separate the location and UEID claims in evidence from results?
> 
> Then maybe when “evidence.location” occurs in an attestation results token you
> know it was passed through?

This is a reasonable way to build things bottoms up.  But being unambiguous can be hard -- this is one reason why namespaces are defined top down.  (E.g., what if you have two Verifiers for different aspects of the appraisal.  Should objects be able to prepend each claim with a (maskable) uuid for a specific asserting identity?)
 
> In this idea, the structure (e.g., the CDDL) for evidence.location and
> results.location would be identical.

I think by structure you mean that ".location" is strongly typed, and the domain of assignable values is consistent between Attester and Verifier.  And I like this approach as it enables interworking/portability of data object definitions.
 
> I’m pretty sure I’m not in favor of this. I’m just given an example to try to
> understand.
> 
> 
> Where this rat holes for me is that the behaviors of the Attester and the Verifier
> are so widely varying here that it seems not possible to pin them down in an IETF
> standard. Instead you as an RP must understand on a case by case basis what
> the Attester and Verifier are doing to know how to trust it.

This is exactly the case.  The RP needs to understand what claims it might trust from a specific Verifier, and what claims it might trust from a type of Attester.  If we can't agree on *some* generalized unambiguously named claims across the domain of RATS use cases, there is little reason for RATS to be a single WG.

> For example,
> 
>  — The location evidence could come from a US satellite, a Russian satellite,
> WiFi location maps created by Google, Cellular triangulation from Verizon
> and/or combinations of the above
>  — The Verifier could just verify the signature and pass it on, could cross check
> the location against the IP address based location service, could ask the carrier
> for triangulation based on the IMEI,...
> 
> There’s no way we here in RATS can sort this variation in trustworthiness for
> location, nor for most other claims. Maybe there are a few claims we can lock
> this down for, but in general we shouldn’t even try.

Agree.  It is up to the RP to determine which objects it accepts as trustworthy from a specific Verifier.

> As an RP you have to go read the marketing description, service agreements and
> such for a verifier service to know what it is going to do for you, not the IETF
> standard.

The object names can be consistent.  It is the identity of a specific Verifier which drives you to trust it or not.

Eric

> LL
> 
> 
> 
> 
> 
> 
> There are alternatives to doing this with namespaces.  But we no proposals
> going down this path yet.
> 
> Eric
> 
> > -----Original Message-----
> > From: RATS <mailto:[e-mail]> On Behalf Of Smith, Ned
> > Sent: Tuesday, February 22, 2022 3:31 PM
> > To: Laurence Lundblade <mailto:[e-mail]>; Henk Birkholz
> > <mailto:[e-mail]>
> > Cc: mailto:[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" <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
> > <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
> > mailto:[e-mail]
> > https://www.ietf.org/mailman/listinfo/rats