Draft: draft-ietf-rats-architecture

Commentary: Signed - off - by :
Paragraph (version B):
There are multiple possible models for communication between an
Attester, a Verifier, and a Relying Party.  This section includes
some reference models, but this is not intended to be a restrictive
list, and other variations may exist.
Paragraph (version B):
In this model, an Attester sends Evidence to a Verifier, which
compares the Evidence against its Appraisal Policy.  The Verifier
then gives back an Attestation Result.  If the Attestation Result was
a successful one, the Attester can then present the Attestation
Result to a Relying Party, which then compares the Attestation Result
against its own Appraisal Policy.
Paragraph (version B):
Since the resource access protocol between the Attester and Relying
Party includes an Attestation Result, in this model the details of
that protocol constrain the serialization format of the Attestation
Result.  The format of the Evidence on the other hand is only
constrained by the Attester-Verifier attestation protocol.
Paragraph (version B):
The passport model is so named because of its resemblance to how
nations issue passports to their citizens.  The nature of the
Evidence that an individual needs to provide to its local authority
is specific to the country involved.  The citizen retains control of
the resulting passport document and presents it to other entities
when it needs to assert a citizenship or identity claim, such as an
airport immigration desk.  The passport is considered sufficient
because it vouches for the citizenship and identity claims, and it is
issued by a trusted authority.  Thus, in this immigration desk
analogy, the passport issuing agency is a Verifier, the passport is
an Attestation Result, and the immigration desk is a Relying Party.
Paragraph (version B):
In this model, an Attester sends Evidence to a Relying Party, which
simply passes it on to a Verifier.  The Verifier then compares the
Evidence against its Appraisal Policy, and returns an Attestation
Result to the Relying Party.  The Relying Party then compares the
Attestation Result against its own security policy.
Paragraph (version B):
The resource access protocol between the Attester and Relying Party
includes Evidence rather than an Attestation Result, but that
Evidence is not processed by the Relying Party.  Since the Evidence
is merely forwarded on to a trusted Verifier, any serialization
format can be used for Evidence because the Relying Party does not
need a parser for it.  The only requirement is that the Evidence can
be _encapsulated in_ the format required by the resource access
protocol between the Attester and Relying Party.
Paragraph (version B):
However, like in the Passport model, an Attestation Result is still
consumed by the Relying Party and so the serialization format of the
Attestation Result is still important.  If the Relying Party is a
constrained node whose purpose is to serve a given type resource
using a standard resource access protocol, it already needs the
parser(s) required by that existing protocol.  Hence, the ability to
let the Relying Party obtain an Attestation Result in the same
serialization format allows minimizing the code footprint and attack
surface area of the Relying Party, especially if the Relying Party is
a constrained node.
Paragraph (version B):
The background-check model is so named because of the resemblance of
how employers and volunteer organizations perform background checks.
When a prospective employee provides claims about education or
previous experience, the employer will contact the respective
institutions or former employers to validate the claim.  Volunteer
organizations often perform police background checks on volunteers in
order to determine the volunteer's trustworthiness.  Thus, in this
analogy, a prospective volunteer is an Attester, the organization is
the Relying Party, and a former employer or government agency that
issues a report is a Verifier.
Paragraph (version B):
One variation of the background-check model is where the Relying
Party and the Verifier on the same machine, and so there is no need
for a protocol between the two.
Paragraph (version B):
It is also worth pointing out that the choice of model is generally
up to the Relying Party, and the same device may need to attest to
different Relying Parties for different use cases (e.g., a network
infrastructure device to gain access to the network, and then a
server holding confidential data to get access to that data).  As
such, both models may simultaneously be in use by the same device.
Paragraph (version B):
combination shows another example of a combination where Relying
Party 1 uses the passport model, whereas Relying Party 2 uses an
extension of the background-check model.  Specifically, in addition
to the basic functionality shown in backgroundcheck, Relying Party 2
actually provides the Attestation Result back to the Attester,
allowing the Attester to use it with other Relying Parties.  This is
the model that the Trusted Application Manager plans to support in
the TEEP architecture I-D.ietf-teep-architecture.