Re: [Rats] Attestation Timing Definitions

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

Hi Ned,

 

From: Smith, Ned, March 10, 2020 5:26 PM



I second Laurence’s point about Attester sending AR to a RP or Attester sending Evidence to RP. 

The use case would benefit from separating ‘entity’ from ‘role’. The entity implementing the RP also implements a Verifier (V2) (This is because Evidence at time k is different from Evidence at time f. 

 

<eric> Agree.  Hopefully my answer to Laurence clarified that.   If at some point we desire to place a sequence diagram into a draft, then we absolutely need to ensure each row is easily referenceable.

 

Might be better to name them Evidence-E1 (at time f) and Evidence-E2 (at time k). Now the diagram can show E2 from Attester to Verifier-V2.

 

<eric> This is fine with me.  Right now I show "Attestation Result + Evidence".   But there is actually more than that in the variant of the Passport from draft-voit-rats-trusted-path-routing.

 

The RP is accepting two inputs AR1 (at time i) and AR2 (at time h). Note: AR at time k is actually mislabeled Evidence-E2, but also includes a “passport”(?) which is AR1. 

 

<eric> Agree.  Hopefully my answer to Laurence clarified that.   

 

What isn’t shown is AR2 which passes from V2 to RP. This is uninteresting from a standards perspective because it is a local flow. It is interesting from an architecture perspective because the third entity needs policies for both Evidence and A.Results and has to account for all the time variables. 

 

<eric> Wei's email contains a good depiction of this flow.

 

Eric

 

-Ned

 

From: RATS <[e-mail] <mailto:[e-mail]> > on behalf of Laurence Lundblade <[e-mail] <mailto:[e-mail]> >
Date: Tuesday, March 10, 2020 at 2:05 PM
To: "Eric Voit (evoit)" <evoit=[e-mail] <mailto:evoit=[e-mail]> >
Cc: "[e-mail] <mailto:[e-mail]> " <[e-mail] <mailto:[e-mail]> >
Subject: Re: [Rats] Attestation Timing Definitions

 

 

 

On Mar 10, 2020, at 1:09 PM, Eric Voit (evoit) <evoit=[e-mail] <mailto:evoit=[e-mail]> > wrote:

 

2. Nonce based Composite Evidence Passport.  

This figure matches to the sequence diagram from Figure 3 of draft-voit-rats-trusted-path-routing

   ...----------.                     ...----------.  .---------------.

   | Attester |                     | Verifier |  | Relying Party |

   '----------'                     '----------'  '---------------'

      time(a)                             |               |

      time(b)                             |               |

        |                               time(c)           |

        |<-----nonce--------------------time(d)           |

      time(e)                             |               |

        |------Evidence---------------->time(f)           |

        |                               time(g){@time(h)} |

        |<-----Attestation Result-------time(i)           |

        |                                 |             time(c)

        |<-----nonce------------------------------------time(d)

      time(e)                             |               |

      time(j)                             |               |

      time(k)--Attestation Result---------------------->time(l)

        |                                 |             time(h)

 

Something seems off here. By my understanding of the passport model, the Attestation Result is the passport and can only be created by a Verifier. This diagram seems to show the Attester creating there Attestation Result. 

 

Seems like one fix is to remove the second nonce and time(e) and say the the Attestation Result is exactly the same in both occurrences — classic passport where the attester just passes the result through.

 

The other fix is to have the Attester produce a second Attestation Evidence that includes the first Attestation Result, route that to a second verifier and then on to the RP. Then you have composition.

 

I don’t think Attesters can produce Attestation Results.

 

LL