Re: [Rats] Entity vs. role

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

Hi Laurence,

 

From: Laurence Lundblade, March 22, 2022 4:31 PM



On Mar 22, 2022, at 9:12 PM, Thomas Fossati <[e-mail] <mailto:[e-mail]> > wrote:

 

On Tue, Mar 22, 2022 at 6:42 PM Laurence Lundblade
< <mailto:[e-mail]> [e-mail]> wrote:




Agree entirely with what’s below, but it doesn’t quite address what I am on about.

RATS architecture clearly separates two polices:
  1) Appraisal Policy for Evidence
  2) Appraisal Policy for Results

The first one is used only by the Verifier role and never by the Relying Party role. It can only be use to process Attestation Evidence, never to process Attestation Results. In a chain of Verifiers all the intermediate results are Attestation Evidence, never Attestation Results.

When all the Verifiers are done, then you have Attestation Results.

Similarly, the Appraisal Policy for Results is used only by the Relying Part role, never by the Verifier role. It can never be applied to Attestation Evidence.

Since we are talking roles not entities, here, the Relying Party can *never* by definition receive Attestation Evidence. Again, since we’re talking *roles* not entities, a Relying Party can *never* host a Verifier.

Said another way, the definition of the Verifier and Relying Party roles gives a hard one-way transition from Evidence to Results.


I think the Verifier and the Appraisal Policy for Evidence is all about the device/implementation/attester.
- Who made the device?
- Is it configured correctly?
- Is it in the right state?
- Does it have the right SW?
- What certifications does it have?

This is represented in the Attestation Results, perhaps in summary or in detail.

Then the RP and the Appraisal Policy for Results is about the application-specific stuff:
 - Is this device OK for this dollar amount (the RP knows the $ amount, not the Verifier)
 - Can this content be played on this device — the RP knows which device and what characteristics it requires for the content
 - Is the sensor data accurate — the RP knows which sensors it can trust


I think that the terminology choice made by the architecture is quite
precise: "AP for attestation results."

The appraisal logic you are describing above covers more ground than
just attestation results.  The way I picture myself the "complete"
appraisal process done by the RP looks more or less like:

         AP for AR
             |
      .------v-------.    .--------------------------------.
AR -> | AR appraisal | -> | Application-specific appraisal | -> [0..1]
 :    '--------------'    '--^--------^---------^----------'
 :                           :        |         |
 '- - - - - - - - - - - - - -'        other     application-
                                      input     specific
                                                policy

 

 

Yes, we can depict it like that conceptually, but in reality it could be one big machine learning engine or similar where you can’t separate it (you could even put unverified measurements in AR so they can be fed into a machine learning engine).

 

<eric> Ar4si uses the term "AR-Augmented Evidence" to show what flows into the unified Verifier + Relying Party roles.  Ar4si makes no assertions on what the full set of Evidence might include.

 

And RATS architecture doesn’t care about what’s in AP for AR and shouldn’t care about it. We’re only mentioning AP for AR for the sake of completeness. We’re not going to put any requirements on it or say anything more about it than it exists, right? Hope that right. 

 

<eric> The RATS architecture doesn't name specific objects.  But where AR flows between devices (e.g., in the passport model), this WG needs to understand how reusable Verifier generated objects/definitions might be consumed.  I.e., the ultimate consumer of RATS is the RP.

 

Eric

 

LL