Re: [Rats] Entity vs. role

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

The RATS architecture purposefully separates application specific aspects of the RP from the attestation specific parts and doesn't try to define the application specific aspect of RP. You might consider the appraisal policy for AR is different from other RP policies that are application specific such as "is this device OK for this dollar amount". 
Appraisal policy for AR would instead focus on whether "who made this device" or "is it in the right state" are meaningful and relevant given the RP's application domain. One might expect the RP and Verifier would negotiate which claims are meaningful and relevant (maybe as part of setup?). 

-Ned

On 3/22/22, 7:42 PM, "Laurence Lundblade" <[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 don’t see this separation as hard as long as we’re open and flexible about what is in Attestation Results. Seems we need to be a bit flexible about what is in Attestation Results because the roles of Verifier and RP are sharp and one-way.

    LL





    > On Mar 22, 2022, at 4:14 PM, Thomas Fossati <[e-mail]> wrote:
    > 
    > hi Ned
    > 
    > On Tue, Mar 22, 2022 at 1:13 PM Smith, Ned <[e-mail]> wrote:
    >> 
    >> (not as chair)
    >> 
    >> One of the topics discussed during RATS113 session I seemed to focus on architectural considerations for entities vs. roles. The architecture draft summarizes concisely:
    >> 
    >> “In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this document.”
    >> 
    >> 
    >> 
    >> This is different from a distributed Verifier that operates on a portion of a conceptual message and (possibly) forwards a portion for some other Verifier to consume. The architecture didn’t attempt to name partially processed conceptual messages distributed across multiple entities.
    > 
    > I fully agree with this.
    > 
    >> It may be helpful for drafts to give names to partially processed conceptual messages
    > 
    > As you say, a Verifier implementation can fraction and distribute the
    > appraisal box the way it wants.  It seems to me though that trying to
    > name these intermediates equates to making the internal
    > (implementation-specific) interfaces explicit, which is something we
    > should really avoid at least until we decide it's time to revise the
    > architecture to break down the Verifier box.
    > 
    >> but until processing is complete (and therefore becomes a different conceptual message) it should still be correct to refer to the partially processed conceptual message by it’s architectural name (e.g., Evidence that has been authenticated but not appraised would still be regarded as Evidence architecturally. Appraisal results that haven’t been authenticated to a Verifier might still be called Evidence up until all the requirements for being called Attestation Results are satisfied.)
    > 
    > I also fully agree with this.
    > 
    > -- 
    > Thomas
    > 
    > _______________________________________________
    > RATS mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/rats