►
From YouTube: RATS Architecture Design Team, 2020-02-25
Description
RATS Architecture Design Team, 2020-02-25
B
C
A
D
A
B
A
A
Dad
we
were
just
going
through
the
high
level
trying
to
figure
out
which
which
issue
we
should
we
can.
We
can
progress
quickly
on
which
ones
will
take
more
time
noting
we
noted
that
the
two
of
the
pull
requests
haven't
really
been
edited
or
updated
since
two
weeks
ago.
So
I
guess.
The
question
is
to
both
this
one
is
already.
B
A
B
So
what
what
Michael
and
I
talked
about
at
hackathon
is?
It
may
still
be
useful
in
addition
to
this,
to
have
you
know
an
example
that
includes
an
actual
implementation
story
that
has
is
right
now.
This
is
very
generic
right,
it
doesn't
say
whether
its
background
or
background
check
or
passport,
because
it
could
be
either
one.
In
addition
to
this,
it
might
be
useful
to
have
a
more
specific
instantiation
walkthrough,
but
that
could
be
done
in
a
separate
pull
request,
whether
it's
in
a
different
section
or
the
same
section
or
whatever.
Well,.
A
F
D
D
With
that
I
want
to
give
Paul
the
opportunity
to
maybe,
as
a
suggestion,
to
skim
the
actual
use
case
document,
and
maybe
you
can
find
yourself
or
your
use
cases
in
there
and
if
you
don't,
maybe
take
them
as
an
example
to
create
your
own.
So
this
is
basically
Michael's
recommendation
operationalized,
because
you
have
to
find
yourself
in
this
use
case
section
and
if
you
do
not,
that
might
be
a
gap
we
have
to
surface.
So
that
is,
would
be
a
message
to
my
turn.
Thanks.
F
A
A
B
For
me,
one
of
the
lowest
hanging
fruits,
which
I
don't
know
if
it
needs
discussion
or
if
it
just
needs
to
be
done,
is
the
one
that's
the
section
ordering
one
that
moved
such-and-such
before
such
and
such
never
know
where
that
one
was
section
yeah
34
is
one
of
the
easiest
ones
to
do.
I
just
don't
know
if
it
requires
discussion,
maybe
you
maybe
we
pull
up
the
table
of
contents
and
decide
whether
we
agree
that
4.1
should
move
down
or
six
should
move
up
or
something
like
that.
A
B
A
B
Franca
says
in
both
models:
the
ax
tester
should
trust
the
verifier
I.
Don't
believe.
That's
true
I'm.
Looking
at
the
comment
at
the
bottom
here,
he
says
yes,
my
put
in
my
point
is
for
both
models.
He
says
there
should
also
trust
the
verifier
I.
Do
not
believe
that
that
is
true,
I
think
in
the
hold
on
maybe
I'm
backwards
hold
on
I
got
I.
Read
it
too
again.
Here.
G
You
I
understand
his
opinions.
Why
you,
in
their
way
and
in
the
background
check
moto
that
has
to
receive
the
testing,
resulted
from
the
verifier,
so
it
needs
to
transfer
the
verifier.
So
you
write
this
in
the
inception,
but
in
the
passport
mode
of
the
results,
the
a
tester
are
tested
that
hasn't
received
a
a
testing
result
from
the
verifier.
So
you
you
didn't
write
this
I
think.
B
B
Because
what
I'm
wondering
is,
if
this
is
an
error,
where
it
should
be
saying
in
solutions
following
the
passport
model,
is
what
I
was
I'm
just
trying
to
read
through
this
again,
because
I'm
wondering
if
background
check
should
be
passport.
But
is?
Is
there
text
in
here
that
talks
about
the
passport
model
and
of
what
I'm
scanning?
For
because
this
might
be
an
error?.
B
In
the
background
check,
the
ax
tester
doesn't
have
any
relationship
with
the
verify
right.
He
sends
it
over
to
the
relying
party.
No
lying
party
picks
the
verifier,
so
certainly
the
relying
party
picks
the
verifier
with
the
attest
or
may
have
no
knowledge
as
a
verifier.
That's
why
I'm
wondering
if
background
check
of
that
sentence
is
supposed
to
be
passport.
B
D
B
So,
just
in
the
analogy
of
you
know,
I'm
doing
a
job
application
or
a
loan
application
I,
don't
even
have
any
knowledge
that
there's
some
background
check
agency.
That's
doing
you
know
the
background
check
of
the
financial
check
or
whatever
I.
Don't
have
any
trust.
In
that
thing,
that's
up
to
the
relying
party
he
chooses
that
and
I
don't
even
have
any
knowledge
of
it.
B
E
E
B
B
E
B
The
passport
model,
the
attest,
are
certainly
trust,
the
the
verifier,
because
you
send
your
evidence
off
to
it
and
you
get
back
your
attestation
result.
You
just
apply
that
to
all
of
the
things
and
so
you're
trusting.
If
that
thing
is
giving
you
the
right
ticket
that
you
can
do
what
you
need
to
do,
you
have
an
excuse
and
you're
the
one
that
has
chosen
the
verifier
right,
and
so
you
have
some
trust
because
you're
choosing
it.
E
A
B
A
Guess,
you're
trusting
them
also
in
the
sense
because
you
may
need
to
reveal
personal
information
or
whatever
to
them
and
you're
you
you.
So
you
have
some.
So
you
have
some
expectations
there,
but
I
just
I
find
it
difficult
to
say
that
this
word
is
trust.
I,
don't
I,
don't
think
the
paragraph
entirely
I
think
I
would
just
strike
the
whole
paragraph.
I,
don't
I,
don't.
E
E
There's
a
privacy
consideration,
I,
don't
know
if
it
belongs
in
the
trust
model
section
then
a
tester
is
is
divulging
information,
that's
potentially
privacy
sensitive,
and
there
appears
to
be
no
control
over
that
once
he
divulge.
Is
it
to
somebody
whether
it's
a
verifier
or
a
relying
party
or
somebody
else
who's?
You
know
what
your
pick
your
model.
E
B
Think
that
is
a
good
point
and
I
think
that
might
actually
be
useful
to
mention
the
trust
model.
Section
I
think
it
was
Michael.
You
had
said
that
your
listing
for
PII,
and
so
that
might
be
useful
to
say,
is
that
in
the
wandering
here
it
seems
like
the
tester
in
the
certainly
trusts
anybody
that
it
sends
evidence
to
for
for
confidentiality
right
so
and
it's
a
background
check
is
trusting
the
verifier
and
then
sorry
in
passport.
It's
trusting
the
verifier
and
I'm
background
check
as
stretching
the
relying
party.
B
C
B
A
F
E
B
A
The
background
check
the
tester
may
also
be
showing
his
evidence
to
the
relying
party
in
the
background
check.
Yes,
yes,
correct,
yes
and
I'm,
just
don't
think
we
have
any
scenario
in
which
some
scenarios
evidence
may
contain
sensitive
information
person
identified
affirmation.
Okay,
that's
a
good
word.
B
Correct
and
in
the
background
check
model,
it
doesn't
make
sense
because
in
general,
because
the
ax
tester
doesn't
know
who
the
verifier
is
yeah
boys,
the
relying
party
right,
and
so
it
doesn't
make
sense
to
encrypt
that's
right.
So
that
means
you're
implicitly
reviewing
the
evidence
tooth.
They
were
lying
already,
even
though
they're
relying
party,
we
just
treats
it
as
opaque
right
guarantee.
If
he's
in
a
furious.
If
he's
not
gonna,
look
into
it.
E
I
think
there
are
no
concepts,
I
mean
yeah.
If
the
a
tester
had,
as
had
a
security
association
with
the
verifier
but
opened
a
connection
to
the
relying
party,
you
could
certainly
encrypt
it
to
the
verifier,
and
the
party
obviously
has
nothing
more
to
do
with
it
than
to
read
the
forward
it
on
to
the
verifier.
D
F
D
What
Ned
said
that
we
have
this
understanding
of
the
source
of
confidential
information
that
sometimes
you
have
to
encrypt
it,
and
sometimes
you
don't
might
don't,
because
we
should
save,
and
then
you
have
the
trust
worth
its
and
the
believability
of
the
residing
in
entities
here.
So
I
think
these
are
concepts
actually
because
you
might
want
to
encrypt
something
because
it's
obviously
conveyed
in
the
open,
and
that
is
about
you
and
you
don't
expose
anything,
and
that
has
nothing
to
do
with
how
much
you
trust
into
the
business
as
I
very
verify,
for
example.
B
Same
thing
is
true
for
the
airline.
Just
like
your
last
sentence.
There
is
right
I,
like
the
last
sentence
you
have
there
and
it
also
means
in
that
case,
you're
lying
party
is
also,
and
so
this
is
a
it's
fine
to
say
that
explicitly.
Just
like
you
did
there
I'm
looking
I'm,
not
sure
about
your
third
sentence,
but
I'm
staring
at
trying
to
wordsmith
like
your
last
sentence,.
B
A
And
we
don't,
we
don't
in
general,
have
I
Ned
said
that
we
could
have
a
relationship
between
the
ax
tester
and
the
verifier
in
the
background
check
model,
but
I,
don't
know
that
we
and
and
that's
maybe
a
feature
some
things
but
I,
don't
know
in
general.
How
that
would
work
and
I
don't
think
that's
a
requirement
where
architecture
is
putting
on
the
model.
B
B
E
It
should
say
more
than
just
the
relying
party
it's
if
you
think
about
it
in
the
context
of
the
hybrid
model.
We
basically
the
architecture
said:
oh,
it
gets.
It
can
be
arbitrarily
more
complicated
than
this
simple
than
the
simple
case
of
passport.
Our
background
check,
and
so
in
this
case
it's
maybe
so.
A
D
E
E
B
E
A
E
B
The
simple
role
relationship
is,
look
I,
don't
think,
there's
anything
to
add
because
right,
the
ax
tester
automatically
has
the
evidence,
because
that's
who
creates
right,
the
verifier
always
gets
the
evidence
is
that's.
The
definition
of
evidence
is
what
those
two
a
verifier-
and
this
is
just
saying
the
evidence
also
goes
to
relying
parties
once
this
true
that
all
the
roles
get
the
evidence,
there's
no
other
gaps
right
yeah.
If.
A
It
was
a
pure
passport.
It
could
be
some
hybrid
of
passport
model
with
multiple,
multiple
relying
parties
and
multiple
verifiers
and
if
they're
all
passport
models,
then
it's
possible.
The
relying
parties
never
see
the
evidence,
but
in
all
their
the
cases,
all
the
parties
get
to
see
the
evidence
matter.
B
E
C
E
B
B
G
B
A
B
So
in
this
one
here
is
its
routing,
but
the
tester
in
this
one
doesn't
necessarily
know
who
the
verifier
is
up
top,
and
so
you
can't
necessarily
have
an
encrypted
channel
there
cuz.
This
is
the
background
check
model.
The
relying
party
to
is
the
one
that
gets
to
choose
the
verifier
and
the
ax
tester
has
no
knowledge
of
that.
If.
E
B
This
example,
because
the
top,
because
the
vertical
lines
are
being
defined
as
the
background
check-
that's
not
possible,
you
can
only
do
integrity.
You
can't
do
potentiality
in
the
data
itself
because
it
doesn't
know
who
the
verifier
is.
So
there's
no
way
to
do
confidentiality
when
you
don't
know
who
the
recipient
is.
We.
E
E
B
So
this
is
an
example
I'm
looking
at
the
text
strip
of
the
diagram,
relying
party
use
an
extension
of
the
background
check
model
so
I
think
in
this
example.
It's
true
because
it's
defined
as
part
of
the
example
right,
you
can
see
figure
5
the
label
in
the
picture,
says
example:
combination.
There
might
be
other
examples
where
it's
different,
but
to
me
all
the
details
are
better
left
into
a
particular.
F
E
B
A
A
A
Yeah
I
I
think
it's
I
think
while
I
agree
with
you
that
that
model
could
exist,
I
I
find
it
I,
don't
know
when
I
don't
know
how
that
would
work
work
in
practice,
I,
don't
know
what
an
example
would
be
is
what
I'm
trying
to
say,
but
I
I'm
not
not
disputing
that
yeah.
It
could
exist
and
would
be
an
enhancement
because
the
relying
party
would
not,
in
the
background
check,
would
not
get
to
see
the
data
and
and
perhaps
there's
good
environment,
good
reasons.
A
D
D
Assume
that
every
Authenticator
and
Fido
would
know
it's
its
verify,
because
that
one
has
handcrafted
metal
certificates
and
handcrafted
reference
values
for
the
each.
So
actually,
I
would
think
that
in
an
Fido,
every
adjuster
knows
its
verifier
and
even
has
a
pre-shared
secret.
That
should
correspond
any.
E
A
E
A
E
E
But
if
you're
trying
to
talk
about
security,
then
you
then
every
area
you
can
drill
into
it
and
say
well,
what's
underneath
that
arrow
well,
there's
going
to
be
some
study
out
some
litter
and
there's
gonna
be
some
layer
to
you
know
hop-by-hop
thing
I
mean
it's
like
it
gets
really
complicated
and
if
you're
trying
to
say
search
from
a
security
perspective,
you
know
there's
no,
there's
no
attacker
in
between
these
two
entities.
It's
like
I,
don't
know
how
you
come
to
that
conclusion.
Based
on
this
diagram.
D
Assumptions
also
not
helping
so
my
intuitive
point
of
your
finger
fire
is
that
everything
that
is
an
arrow
here
is
a
conveyance
and
no
modification,
so
attestation
results
I,
apparently
created
as
the
verifier
and
relayed
by
the
relying
party
to
and
then
relate
by
the
attest
are
there
is
no
modification
happening
here
from
my
understanding
or
looking
only
at
the
figure.
If
I
read
the
text,
I
might
learn
more
about
figure.
Five,
for
example,
that
a
tester
might
add
something
to
the
attestation
result
and
making
it
evidence
again
could
be
possible.
D
It's
not
in
this
diagram,
but
it
is
a
receivable
procedure,
but
then
the
denying
party
would
want
to
do
something,
those
all
assumptions.
Nothing
of
that
is
happening
here
and
I.
Think.
Therefore
it
should
not.
Should
the
confidentially
part
between
rows,
we
can
just
put
in
a
different
paragraph
and
say
next
to
these
moral
compositions
always
take
care
that
relying
parties,
my
trees,
the
evidence
and
even
meditation
resides,
and
it
might
not
be
for
them.
D
D
E
E
Right
but
let's
assume
that
the
rolls
architecture
allows
for
both
integrity,
protection
and
confidentiality
protection
all
right.
So
if
we
make
that
assumption
than
the
arrow
from
the
attest
er
through
the
relying
party
to
to
the
verifier
is
potentiality
and
integrity
protected,
in
which
case
really
of
evidence
isn't.
E
B
B
B
E
Sure
I
thought
I
mean
I,
think
that
if
it,
if
it
doesn't
already
say
that
the
expectation
of
the
roles
architecture
is
that
the
the
messages
that
flow
between
the
different
roles
and
then
the
most
in
that
simple
expression,
are
our
integrity,
protected
and
and
maybe
or
maybe,
should
be
confidentiality
protected.
If
that,
if
that
wasn't
under
status,
understood
upfront,
then
looking
at
this
diagram,
people
would
not
be
confused
as
to
what
the
role
of
the
of
these
our
arbitrary
routing
decisions
are
I.
D
Am
okay
with
a
forward
reference
if
the
topological
models
require
it
really,
but
I
would
assume
that
net.
You
now
have
the
task
to
make
sure
that
everything
you
want
to
see
about
those
through
orthogonal
things
that
are
integrity
and
confidentiality,
protection
in
the
corresponding
consideration
sections,
and
if
it's
really
necessary.
Oh
my
gosh,
that
we
do
a
forward
reference
here.
It's
fine
with
me,
I,
don't
like
those,
but
but
if
it
helps
to
do
too
and
that
people
understand
these
are
only
flows
and
and
all
the
encryption
and
all
the
signing
is
dead.
D
B
Agree
with
you
that
I
don't
think
that
we
need
to
have
discussion
prior
to
this
concerning
security
consideration
section
unless
it's
absolutely
necessary,
I'm,
not
convinced
that
it's
absolutely
necessary.
If
it
is
then
I'm.
Okay
with
that,
but
I,
don't
think
it
is
yet
and
so
just
making
sure
that
there's
text
in
the
security
considerations,
section
and
I
think
you
are
trying
to
ask
Ned
to
write
that
text
or
verify
that
that
text
is
already
there
in
what
Michael
wrote.
Yeah.
E
D
G
G
D
E
D
D
D
B
D
But
in
any
case,
I
would
maybe
this
is
independent
of
what
you're
just
commenting
on
Dave,
so
if
roads
are
collapsed
on
a
entity.
So
if
a
thing
is,
for
example,
a
verifier
in
the
relying
party
at
the
same
time,
do
these
two
roles
have
a
explicit
automatic
trust
relationship,
so
they
trust
each
other
unconditionally.
Is
that
always
true?
Is
that
our
design
or
architecture
design,
I
assume
it
is
I'm,
not
sure.
D
B
Would
certainly
be
true
to
say,
the
internal
verifier
must
be
trusted
by
the
internal
verifiers
endorser
and
the
internal
verifier
is
owner
before
getting
the
end
or
the
the
endorsements.
That
would
be
true,
but
as
phrase
it
seems
to
be
talking
about
the
remote
verifiers,
endorser
and
verifier
owner,
and
I
think
that
part
would
be
false.
Now,
maybe
that's
the
main
or
something
like
that,
but
that's
not
to
explain
why.
That
would
be
true.
So.
G
D
A
E
Overloading
the
diagram
should
pick
one
and
talk
about
one.
If
the,
if
the
thing
in
the,
if
the
thing
we're
calling
lead
a
tester
is
an
a
tester,
a
local,
you
know
it's
just
as
local
a
tester.
Then
let's
talk
about
that
use
case.
If
the
thing
is
a
verifier,
then
let's
talk
about
that
is
contains
the
case.
I.
A
E
E
A
But
I,
don't
I,
guess
I,
don't
think
it's
so
different,
because
I
think
one
of
the
things
we
were
trying
to
generalize
is
the
case
where
the
leader
testers,
a
testing
environment,
passes
the
evidence
off
to
a
tester
bees.
Verifier
receives
an
attestation
result
back
and
then
provides
that
as
part
of
its
evidence
and
we're
trying
to
blur
the
that
case,
which
is
sort
of
goes
into
a
third
dimension
in
this
diagram.
B
Just
as
a
rule
of
thumb,
I
don't
think
it's
a
good
idea
for
the
architecture
document
actually
include
every
possible
permutation
of
every
combination.
Sorry
again,
I
don't
disagree
with
a
lot
of
discussion,
but
I
don't
necessarily
agree
that
all
the
different
things
need
to
be
in
the
arc
to
in
the
architecture
document.
D
E
We
find
the
relationship
between
Ana,
tester
and
a
verifier
is
evidence
and
their
relationship
between
a
verifier
and
a
relying
party
is
attestation
results
and
we
can
take
those
combinations
and
arbitrarily
overload
them.
You
know
compose
them
and
whatever,
but
it
still
doesn't
change
the
that
you're
passing
the
thing
that
is,
a
local,
a
tester,
still
passing
evidence
to
a
verifier,
and
the
thing
that
is
a
local
verifier
is
still
passing
an
to
station
results
to
something
else
to
a
relying
party,
whether
it's
remote
or
whatever.
E
You
don't
have
to
diff
a
diagram
that
shows
all
the
permutations
for
how
that
works
right,
but
the
reason
that
the
composite
device
was
interesting
is
because
it
says
that
there
is
a
Zanna
tester,
it's
saying
it's
receiving
evidence
and
it's
asserting
another
claim,
which
is
that
it's
composing,
the
the
B
and
C
and
dot
dot
dot
confidence
with
the
a
component.
That's
the
relevance
of
this
diagram.
It's
it's!
This
compose
a
composition
of
structure
which
is
the
important
takeaway
overloading
verifier.
It
makes
it
really
confusing
unnecessary.
A
B
B
B
B
G
C
B
I
would
want
to
talk
about
that
one
more,
but
because
I
think
it
may
be,
because
here
I'm
looking
at
the
the
endorser
has
to
trust
the
verifier
before
giving
the
endorsement
to
it.
I
think
there's
a
lot
of
subtlety
in
there
and
to
say
why
it
may
be
trusting
it
for
confidentiality,
maybe
but
other
than
confidentiality.
I.
Don't
know
that!
That's
true,
when
you
say
need
to
write.
You
can
have
endorsers
that
just
supply
endorsements
to
anybody
who
asks
as
long
as
there's
nothing
confidential
in
them
with
no
trust
whatsoever.
B
G
B
You
get
the
endorsements
from
the
endorser
to
the
verifier
right
if
it's
a
pull
method
mechanism
where
the
verifier
just
goes
and
asks
the
endorser
whenever
it
needs
to,
for
example-
and
this
is
what
intel's
service
does
with
their
currently
deployed
arab
at
the
station,
then
it
doesn't
know
who's
asking
right.
You
can
ask
the
service,
no
give
you
the
the
certificate
or
whatever
it
says.
Yes,
that's
a
valid
Intel
machine.
G
B
Don't
know
I
mean
you
can
say,
may
for
all
kinds
of
different
things:
I,
don't
know
whether
there's
a
reason
for
lots
of
maize
to
be
in
the
architecture
document
and
so
I'd
say
I,
don't
know
yet
because
it's
important
for
there
to
be
maids.
It
actually
affects
what
other
documents
have
to
be
written.
But
if
it's
just
yo
well,
there's
all
kinds
of
different
maize,
I,
don't
know.
If
that's,
why
didn't
you
propose
that
so
save
I've
removed.
A
The
sentence
ok
this
commit
and
which
did
you
remove
the
bottom
we've
been
talking
about
the
bottom
paragraph.
You've
been
talking
about
the
bad
in
forever,
I've
removed
the
part
in
on
the
above
thing,
but
I,
don't
know.
I
I
didn't
quite
we're
talking
about
problems
with
the
other
parent.
You
know
you're
now
talking
about
problems
with
the
other
paragraph.
So
that's
why
I'm
I'm
coming
back
to
the
circle,
so
this.
B
This
part
down
here,
yes
line,
518
I,
think
it's
not
true
at
least
I'm,
not
convinced
that
line
518
the
need
to
I.
Don't
think
that's
true,
and
so
what
we
were
just
saying
is
that
what,
if
need
to
be
came
me
in
there
and
that's
what
I
was
coming,
we'll
sure,
there's
lots
of
other
possible
maize
that
you
could
add.
Why
is
this
one
significant?
If
this
is
a
may.