Re: [Rats] Entity vs. role

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

See inline [nms] – warning long reply

From: RATS <[e-mail]> on behalf of "Eric Voit (evoit)" <evoit=[e-mail]>
Date: Wednesday, March 23, 2022 at 1:54 PM
To: Laurence Lundblade <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "Smith, Ned" <[e-mail]>, Thomas Fossati <[e-mail]>
Subject: Re: [Rats] Entity vs. role

From: Laurence Lundblade, March 23, 2022 4:03 AM
On Mar 22, 2022, at 10:37 PM, Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>> wrote:

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

Yes, went backed and looked at your slides again. Makes sense. Definitely a use case to support.

When talking in terms of roles, I definitely think that Verifier B is just co-located with the RP, not part of the RP.

I’m not sure if we should consider Verifier A + Verifier B a composite Verifier or not. In my comments above I clearly asserted that all the verifiers (in a composite verifier) must have run before there is any AR. By that criteria it is definitely not, but maybe that definition is too strict?

<eric>  There is no term "Composite Verifier" in the architecture.  And if there was, I wouldn't consider Verifier A + Verifier B composite because:
* Verifier A will often not even know about Verifier B.
* Verifier A & Verifier B will often be managed by different organizations.
[nms] The term ‘composite’ is defined in the context of ‘composite device’ which is an entity (not a role). The architecture didn’t define ‘composite verifier’ but if it did it would likely(?) define it as an entity (lower case verifier) – or some other name that avoids collisions with Verifier. Maybe I-Ds that describe different compositions of entities should be careful to use names that are well qualified such as a ‘distributed entity’(de)? Then it would be easier to talk about a Verifier on de-A or a Verifier on de-B. It may seem pedantic but it helps clear up “ambiguities” in the architecture by separating issues related to managing entities from those pertaining to role semantics and appraisal processing / interpretation. Roles focus attention on what can be said while entities focus on who is speaking.

I’m also not sure what we should call the intermediate results between Verifier in a composite verifier. By my criteria above it can’t be AR-Augmented Evidence, but again, maybe that criteria is too strict.

<eric> Verifier A does not know that it is creating "intermediate results".  It is delivering exactly the evaluation promised.  This is why what is coming from the Verifier A must be known as Attestation Results.

It is up to the end-to-end use case as understood by the Verifier B + RP to determine how to handle the full set of Evidence receives.
[nms] +1

Ironic in a way — I want to forward/passthrough Evidence in Results, you are forwarding/passingthrough Results in Evidence :-)

<eric> It is not me that puts Results in Evidence.  It is the definitions in the architecture document which requires it *must* be specified this way.

Others should chime in on whether they agree with my interpretation of the architecture document.  To me it is perfectly clear.
[nms] If entity-A says Evidence-1, AR-1 and Endorsement-1 then we can refer to entity-A as an Attester or Verifier or Endorser or combinations of these roles. But that may lead to confusion if the design needs to describe properties of both the entity and the role(s) it performs. The architecture takes some liberties for readability when describing RATS roles conceptually. Sometimes the roles read like entities. But the terminology section clearly describes the difference between role and entity. Nevertheless, I-D authors may need to be rigorous about distinguishing between properties that apply to entities and those that apply to roles.

Given Evidence is a logical statement that relates “who says what”, the following is an example of a RATS conceptual message:
“entity-X says conceptual message”

There is an implied assertion that “IF entity-X says Evidence THEN entity-X must be an Attester”. However, it is ambiguous whether conceptual message is either Evidence, Attestation Result, RV etc…

A credential that deliberately assigns the Attester role to entity-X would make the role assignment explicit and provable. The logical statement would be something like ‘entity-X has role Attester and says Evidence’. This statement would be cryptographically verifiable if ‘says’ is interpreted as use of a key.

The ‘says’ statement can be used for both role assignments and conceptual message construction.
E.g.,
Statement 1: “owner-entity-Y says entity-X has role Attester”
Statement 2: “entity-X says Evidence”

If statement 2 happened before statement 1 then that would be a security flaw.

Assuming the roles assignment happens in the right order, it is possible for an Evidence passthrough case to be expressed as:
     Setup steps:
Statement a: “owner-Y says entity-X has role Attester”
Statement b: “owner-Y says entity-Z1 has role Verifier”
Statement c: “owner-Y says entity-Z2 has role Verifier”
Statement d: “owner-Y says entity-RP has role Relying Party”

     Operational steps:
Statement 1: “entity-X says Evidence”
Statement 2: “entity-Z1 says (entity-X says Evidence)” ; passthrough evidence
Statement 3: “entity-Z2 says AR” ; and includes entailment for Statement 2

Alternatively, statement 3 could include the entailment in a single statement:
Statement 4: “entity-Z2 says (entity-Z1 says (entity-X says Evidence))”

The first parenthetical is the partial attestation result expressed as passthrough evidence. The RP might want AR claims expressed using the same format as was expressed by the Attester Evidence. Let’s say the claim is 264 (which is the IANA code point for location) with x,y,z coordinates.

    e.g.: Statement 4: “entity-Z2 says (entity-Z1 says (entity-X says 264=(x,y,z)))”

The RP might want to consume a claim in the ‘264’ format, but also wants to know that it was intended as AR and NOT Evidence that was routed through entity-Z1 or entity-Z2 where it picked up a signature as a consequence of secure routing protocols.

Based on this, Statement 2 and Statement 4 are passing evidence through, but it is partially appraised Evidence.

For example, Entity-Z1 might have an appraisal policy that requires Evidence to contain 3 different location sensing techniques (GPS, triangulated cell towers, and Bluetooth RSSI). The result of Z1 appraisal might result in only GPS location because Z2 expects Z1 to apply data reduction resulting in an intermediate form of Evidence that is a singleton location and partially appraised.

Entity-Z2 might process the location claim based on a Reference Value in the form of a geo-fence. If inside the fence, the location claim is propagated otherwise not. If propagated then it becomes an AR.

Even though the claim delivered to the RP is the same value encoding (264) as originally produced by entity-X as Evidence. The RP can determine that it is indeed Attestation Results in two ways.

(a)     By evaluating policy about who can say what (refers to the setup steps).

(b)     By evaluating a log of the statements (1-4) and determining if the statements have logic or sequencing errors.

Since Z1 and Z2 behavior are modified by appraisal policy. Statement 4 should include the policies they applied. Something like the following:

Statement 4: (entity-Z2 says (entity-Z1 says (entity-X says 264) by policy-Z1) by RV-Z2)

Since reference values are provided by RVPs. A RV is a statement of the form:
     (RVP says RV1) where RV1 is a geo-fence with four corners (264=c1, 264=c2, 264=c3, 264=c4)

Statement 4 then might be:

(entity-Z2 says (entity-Z1 says (entity-X says 264=(x,y,z) by policy-Z1) by (RVP says (264=c1, 264=c2, 264=c3, 264=c4)))

Note: Everything to the right of a “says” operator is a conceptual message.

Architecturally, statement 4 isn’t Attestation Results until the outer parenthesis is applied. Prior to that it is Evidence. I.e., (signed) appraised Evidence = AR.

From a RP perspective it is “un-appraised Attestation Results” until statement 4 is evaluated (appraised). It isn’t actionable by a RP-entity before then. It might make sense to call it “appraised AR” to clarify within the RP-entity what phase of processing it is in. From an RP-entity perspective, the line where the RATS RP Role crosses over to the RP-entity’s enforcement role occurs when an appraised AR exists. Prior to that it is just Attestation Results.



Eric

LL