►
From YouTube: IETF115-IOTOPS-20221108-1300
Description
IOTOPS meeting session at IETF115
2022/11/08 1300
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
Okay,
so
welcome
everybody.
This
is
the
ietfs
115
London
hybrid,
meeting,
iot
operation
working
group
session.
Welcome
in
the
room
welcome
all
over
the
world
in
all
the
time
zones
good
morning
good
afternoon
good
evening,
and
first
of
all,
this
session
has
been
recorded.
A
That's
part
of
the
rules,
so,
if
you're
not
familiar
with
the
rules,
there's
something
called
the
note
Bell.
Most
of
you
are
probably
very
aware
of
that.
I
want
to
highlight
that
a
few
are
you
being
recorded
here,
say
something
that's
IP
related,
so
maybe
read
the
code
of
conduct
and
copyright
BCPS
listed
here.
Also,
we
have
a
pretty
easy
rule
that
that
we
are
only
talking
to
people
in
a
way
like
that
we
bought.
A
We've
talked
at
so
be
nice
to
each
other
and
going
from
there
there's
a
agenda
Tool
agenda
page
at
the
data
tracker.
If
you
are
in
the
room,
we
also
must
virtually
raise
your
hand,
that
is,
for
the
fairness
for
the
remote
attendees,
so
remote
attendees
and
on-site
attendees
have
the
same
way
to
queue
for
a
mic.
A
So
the
lower
Arrow
points
to
the
tool
at
the
agenda
site
where
you
can
click
for
the
on-site
tool
and
that's
basically
a
rest
hand
and
item
and
a
chat
icon
so
going
from
here
we
have
a
agenda
that
is
apparently
already
on
the
side.
We
will
talk
about
that
in
a
few
minutes.
If
you
find
some
issues,
I
think
that
the
most
important
thing
here
as
a
resource
record
them,
you
find
a
new
recorder,
bug
bug
item
at
the
data
tracker,
basically
everywhere
since
a
few
weeks.
A
So
if
you
find
something,
that's
not
working
out
for
you,
please
issue
that,
and
now
coming
to
the
actual
iotops
session,
my
culture
Alexei
and
me
I'm,
Hank
I
will
lead
to
this.
We
already
have
two
volunteers
for
chat
scribes,
so
we
can
skip
that
item.
The
minutes
are
at
the
echo
so
you're,
probably
aware
of
those,
and
we
have
a
relatively
full
agenda
for
today,
starting
with
the
biggest
item
off,
and
that
is
I
think
interesting
for
everybody
to
follow.
I
assume
an
ID
that
we
could
maybe
adopt.
A
C
Sorry
are
we
going
to?
There
was
some
agenda
bashing
request,
so
Elliot
asked
to
be
first
because
he
has
to
be
in
another
meeting.
So
if
there
are
no
objections,
we'll
let
Elliot
so
device
schema
extension
for
skim
will
be
first
and
then
we'll
continue
with
the
rest
of
the
agenda.
A
Things
that
looks
almost
just
said
that
two
minutes
ago,
so
my
goldfish
brain,
probably
missed
that
going
going
with
the
discussion
of
draft
Brandon
will
show
us.
We
have
I'm
not
going
to
read
to
you
the
whole
agenda.
We
have
a
full
agenda.
There
was
once
upon
a
time
the
opportunity
for
any
other
business.
That's
only
available
if
someone
is
faster
than
expected
going
from
here,
I
think
we
can
start
sharing
Elliott's
content.
So
let
me
quickly
go
to
the
reshare.
D
D
Right,
can
you
hear
me
Tim
got
it
there.
It
is
all
right,
so
I'm
gonna
try
and
give
you
back
a
little
bit
of
time
right.
So
this
is
about
skim
for
devices
system
for
cross
I,
cross
domain
identity
management
for
devices.
This
is
work
on
behalf
of
myself,
Muhammad
shahzad
and
Hassan
iqbar,
who
the
the
former
two
are
at
the
North
Carolina
State
University.
Next
slide.
Please,
oh
yeah!
That's
me!
Sorry,
all
right!
D
So,
as
this
group
knows
more
than
everybody
else,
there
are
a
zillion
ways
to
do
on
device
onboarding,
and
so
we
asked
a
question
from
an
administrator's
standpoint
right.
In
fact,
we
asked
four
or
five
questions
from
an
administrative
standpoint.
Number
one
is
how
do
I
provision
a
new
device
into
new
infrastructure
number
two
is
how
to
establish
the
bootstrapping
credentials
for
that
device
for
a
particular
mechanism
right.
D
So
if
you
have
different
devices
using
different
mechanisms,
how
do
you
know
which
one
third
is,
what
sort
of
ancillary
information
would
I
like
to
provision
as
well,
where
that
information
comes
from
I'll?
Tell
you
in
a
moment
and
four
is:
how
do
I
get
application?
Api
information
for
non-ip
based
infrastructure,
that
is
to
say,
if
you
have
a
ble
or
a
zigbee
or
some
other
non-ip
device,
and
you
want
to
Tunnel
requests
to
from
them.
What
are
the
API
endpoints
for
that?
D
So
these
are
sort
of
the
sort
of
information
that
you
might
want
when
you're
provisioning
advice.
Well,
the
question
is,
and
let's
start
with
who
the
I
is,
the
I
could
be
a
partner
of
an
Enterprise
or
deployment
saying
here,
I've
sold
you
something
the
the
I
could
be
an
individual
who's
making
use
of
this
through
an
app
and
a
standardized
protocol
to
transmit
the
information.
There
could
be
several
different
values
of
I
here,
but
one
nice
value
of
this
is
if
we
can
all
communicate
the
same
way,
no
matter
who
the
I
is.
D
So
how
can
we
do
this
turns
out
if
we
want
to
bring
all
this
stuff
together,
where
we
have
no
technology
religion
and,
as
this
group
knows,
there's
not
going
to
be
a
king
of
the
Mountain
for
for
onboarding,
nor
King
of
the
mountain
for
transport
Technologies
nor
King
of
the
mountain
for
any
other
thing
in
iot
right,
the
only
thing
I
want
to
know
is
what
is
what
is
being
provisioned
and
and
how
do
I
communicate
with
it?
So
skim
a
system
for
cross
domain
identity
management
does
this
for
users.
D
Today
it's
an
ietf
protocol.
It
allows
for
normalized
set
of
schemas
no
technology,
religion,
that
is
to
say,
don't
care
what
the
mechanism
is
as
long
as
it
can
be
specified
in
a
schema
right.
D
We
provide
in
our
draft.
We
provide
a
couple
of
initial
examples.
We
did
so
for
DPP.
We
did
so
for
ble.
We've
done
so
for
zigbee,
I
hope
to
do
so
soon,
for
matter,
I
hope
to
do
so
soon
for
RFC
8366
vouchers,
maybe
even
anima,
with
a
little
bit
of
help
from
Michael.
In
fact,
we
could
probably
get
that
done.
D
I'm
looking
for
others,
in
other
words
the
table
Stakes,
is
I,
have
to
have
sufficient
information
to
know
how
the
deployment
should
be
communicating
in
order
to
onboard
with
the
device.
So
this
allows
for,
if
you
will
unified
interface,
just
say
what's
getting
plugged
in
and
how
to
take
the
next
step
with
that
thing,
Next
Step
next
slide,
please!
So
why
not
use
other
stuff?
There
are
a
couple
of
other
things
out
there.
We
could
have
used
I'll
go
from
down
from
the
bottom
to
top.
Here.
D
There
are
only
two
choices
that
I
I
selected.
You
might
have
others
SNMP,
simply
no
right,
because
we're
done
with
SNMP,
Yang,
netconf
and
rest
comp
seem
more
like
a
possibility.
But
what
we're?
Really?
What
we're
passing
on
is
provisioning
information
about
devices
we're
not
passing
on
configuration.
It
can
configuration
information
for
those
devices
right.
D
There
could
be
other
meta
information
that
we
want
to
provide,
and
that's
not
what
netconf
and
Yang
offer
or
rest
conf
offers,
there's
no
benefit
in
terms
of
existing
schema
that
help
for
that
purpose.
So
this
is
a
useful
way
to
to
Simply
provide
very
specific
provisioning
information.
The
same
way
you
would
do
for
a
user
when
a
user
is
being
provisioned
onto
a
service
like
WebEx
or
Salesforce,
or
who
knows
whatever
that
skin
is
used
for
today.
So
this
was
our
our
view
for
this
next
slide.
Please
right.
D
We
have
some
basic
elements
that
are
are
present
in
in
any
skim,
schema,
ID,
meta
and
schemas.
These
are
all
from
the
skim
core
schema
which
provide
for
things
like
last
updated
and
such
we
have
a
few
other
things
like
admin,
State
connectivity,
which
is
the
type
of
connectivity.
The
device
has
an
optional
display
name
and
an
optional
mod
URL,
and
it's
optional,
meaning
you
really
don't
have
to
do
it.
If
you
don't
want
to
do
it
next
slide,
please.
D
So
there
are
some
things
to
think
about.
Phil
Hunt
is
is
sort
of
Dr
skim
in
the
way
that
I'm,
Dr,
Mudd
and
and
Michael
is
Dr
anima,
for
instance,
and
Karsten
is
Dr
core.
As
another
example,
Phil
gave
us
a
couple
of
bits
of
feedback.
D
One
of
the
things
we
we
want
to
make
sure
we're
doing
is
skim
created
their
own
schema
description,
language
and
I,
sort
of
want
to
move
away
from
that
and
push
the
and
push
towards
either
adjacent
schema
or
an
open
API
approach,
something
that
is
programmatically
validated,
and
then
we
want
to
make
sure
we
get
the
normalization
right.
D
We
know
we
made
a
couple
of
Goofs
in
the
schema
initially,
in
fact,
I'm
sure
we
made
many,
the
authors
and
I
don't
claim
to
be
skim
experts,
so
we're
going
to
rely
on
the
skin
working
group
to
help
us
on
that
in
terms
of
getting
this
stuff
right
next
slide.
Please.
D
Right
so
we're
hoping
to
discuss
this
on
the
skim
working
group,
the
the
adoption
is
not
for
the
iot
Ops
group.
Rather
for
skim,
we
need
authors,
co-authors,
reviewers,
implementers
and
deployments.
We
want
to
try
all
this
out,
we're
not
tearing
Harry
to
to
push
this
through
the
standardization
process,
though,
what
we
found
in
the
skin
working
group
is
that
others
are
so
there's
there's
a
lot
of
interest
in
doing
something
along
these
lines.
D
Another
use
of
skim
that
people
are
thinking
about
is
workload
provisioning,
which
is
not
something
I'm
interested,
but
we
could.
There
are
common
aspects
to
what
we're
doing
so.
We're
going
to
look
at
that
in
the
same
light
and
see
see
what
commonality
there
is.
There's
a
GitHub
tracker
I
would
love
for
people
to
open
issues,
and
with
that
I'll
pause
for
any
questions
you
might
have.
A
E
Hi
Brenda
hi
Brendan
Moran
at
the
mic,
I
guess
the
question
I
have
I
I,
don't
know
anything
about
skim.
How
is
it
authenticated.
D
Skim,
that's
a
good
question.
So
skim
is
a
restful
protocol,
so
you
have
to
authenticate
each
of
the
endpoints
right,
the
the
one
endpoint
you'll
authenticate.
You
know
that
the
server
you'll
typically
authenticate
with
you
know
your
typical
website
for
client-side
authentication.
I.
Think
you
have
your
choice.
You
can
do
whatever
HTTP
allows
you
to
do
in
that
regard.
You
can
use
a
user-based
authentication
for
users
who
are
doing
authentication
or
you
can
use
a
cert
based,
authentication
or
a
token
based
authentication.
F
Richardson
so,
following
from
Brendan's
question,
the
thing
The
Entity,
that
has
the
credential
is
I.
Guess
the
manufacturer
and
the
the
place
that
it
needs
to
be
provisioned
to
is
the
new
owner.
D
F
At
some
point
it
has
to
be
the
the
owner
the
owner
gets
could
be,
there
could
be,
there
could
be
a
a
chain
of
custody.
Yes,
yep,
okay,.
F
F
Well,
I've
actually
bought
equipment
from
Cisco,
directly
and
I
typically
have
logged
into
Cisco
and
Cisco
has
not
logged
in
to
me.
We
have
no
con.
We
have
no
relationship
that
way.
So
to
me,
that's
a
entirely
brand
new
supply
chain
relationship
where
the
relationship
goes.
The
other
way
around
so
I'm
I
think
that's
the
huge
challenge
for
this.
F
Okay
I
think
it's
far
far
different
a
case
for
skim
where
me
as
functionary
in
HR,
logs
into
Salesforce
and
Provisions,
an
account
for
Elliott
right
because
I'm
going
to
my
service
provider
and
providing
an
account
for
for
you
and
the
relationship
is
that
way,
and
that
makes
sense
to
me
so
I
think
that
there's
there
are
issues
that
are
much
much
bigger
than
I,
then
well,
I,
don't
know
what
the
skin
working
group
wants
to
do
with
that,
but
I
think
that's
a
huge
issue
and
I
suspect
it's
bigger
than
that
working
group
and
I
suspect
it
goes
towards
supply
chain
considerations
and
I.
F
Guess
I
would
encourage
you
to
bring
those
issues
back
to
this
working
group
regularly
and
maybe
you
know,
there's
documents
that
originate
here
or
there
that
cross
whatever.
But
it
to
me
just
seems
like
a
big,
very
big
difference,
okay
and
if
we
could
have
assumed
that
kind
of
relationship
five
or
six
years
ago,
and
maybe
it
was
Impractical
then-
and
it's
practical
now
tell
them
you
tell
me
if
that's
true,
then
we
wouldn't
have
built
brewski
the
way
we
did
right
right.
D
So
I'll
briefly
respond
and
then
we'll
take
it
to
we'll
take
your
advice
actually
right,
which
is
let's
one
of
the
reasons
I'm
here
is
exactly
for
the
reason
that
you
mentioned
Michael,
so
to
provide
a
little
bit
of
of
exchange
of
information,
and
the
iot
Ops
group
is
I.
Think
here
for
that
purpose,
so
the
whether
the
the
that
relationship.
So
in
answer
to
the
first
part
of
your
question,
you
could
imagine
an
app
that
uses
skin
using
a
user
Authentication
that
interacts
with
the
local
infrastructure.
D
G
G
Wi-Fi,
are
you
bad
go
ahead
like
that,
so
I
was
gonna,
say
yeah,
I
Echo,
someone
Michael's
concerned
right.
It
seems
like
the
skim
sort
of
if
they're
thinking
about
users
across
the
main
type
things.
It's
actually
not
the
the
information
flows.
The
dependencies
might
be
in
the
wrong
direction.
Right
and
I
would
be
interested
in
knowing
the
discussion
that
you
had
in
the
working
group
process
yesterday
at
their
meeting
or
sort
of
what
what
was
the
thought
process
there?
D
I
can
give
you
an
example.
Okay,
an
example
is
that
in
the
healthcare
space
there's
a
lot
of
information
Exchange
in
which
data
Lakes
are
formed
in
the
cloud
by
the
by
equipment
providers
and
or,
and
they
also
have
a
Control
Function,
that
is
in
the
cloud,
particularly
for
ble
devices,
so
wearables
that
that
do
like
pulse
Hawks
and
other
things
where
they
want
to
keep.
D
They
want
to
do
control
of
the
device
from
a
cloud-based
perspective,
so
having
an
API
into
that
account
knowing
having
knowing
what
the
API
endpoints
are
and
knowing,
on
the
other
hand,
which
devices
in
the
Enterprises
are
meant
to
be
accessed
by
that
API
is
an
example
that
a
medical
industry
is
very
interested
in
as
an
example.
D
A
second
example:
nurses
stations
like
they're
sold.
You
know,
they're
sold
or
they're
transmitted
to
to
particular
hospitals,
or
something
like
that
and
those
they
want.
The
practitioners
just
to
Simply
Be
able
to
plug
them
in
they
don't
want
to
have
to
worry
about
scanners,
or
things
like
that.
You
know
where
you
you
have
to
use.
The
app
as
say
is
the
model
for
Wi-Fi
Wi-Fi
lines.
Is
Easy
Connect?
D
They
want
to
be
able
to
just
communicate
that
at
Point
at
a
time
of
sale
and
time
of
transfer
even
right,
and
these
are
for
particular
for
critical
infrastructure
where
you
know
you're
going
to
have
a
support
relationship
with
a
vendor.
It's
something
that
you
can
add
some
infrastructure
to
support
to
make
it
easy
on
the
iot
operator.
A
G
A
E
Hello,
so
I'm
here
to
give
you
an
update
on
the
draft
that
I've
been
working
on
it
started
essentially
as
a
next
slide.
Please,
it
started
as
a
summary
of
the
the
things
that
are
going
on
in
the
ietf
that
are
in
and
around
security
and
iot
and
trying
to
make
iot
systems
very
secure.
E
It's
been
Rewritten
twice
now
the
latest
change
Maps
it
more
to
trying
to
reuse
a
lot
of
the
other
work.
That's
been
done
in
the
industry
around
setting
up
Baseline
security
requirements.
So
next
slide
please
foreign
there.
It
is.
The
first
question
is:
is
who's
going
to
read
this
obviously
I'm
not
intending
to
set
normative
requirements
here?
E
So
the
interesting
question
is
who's
going
to
read
a
non-normative
draft,
there's
a
few
options:
people
who
may
want
to
know
what
should
be
in
their
networks
and
what
technologies
they
should
be
using
so
I
think
there's
a
a
useful
space
for
us
to
have
a
landing
pad
for
that
kind
of
information.
Next
slide,
please.
E
There
are
a
lot
of
Baseline
security
requirements,
documents
out
there
and
there's
quite
quite
a
few.
I've
got
three
of
them
listed
here,
but
what
what's
not
in
them
in
general,
is
a
mapping
to
technologies
that
are
actually
available.
In
fact,
the
United
Nisa
one
is
is
quite
interesting
when
it
was
written.
The
security
to
implement
or
the
the
security
technology
to
implement
some
of
its
requirements
didn't
exist
yet,
and
it
was
Baseline.
E
So
that's
you
know
we
we're
working
on
it
and
there
aren't
necessarily
mappings
for
everything,
so
I
think
having
a
draft
that
actually
describes.
Those
mappings
would
be
quite
useful
for
implementers
next
slide,
please.
E
So
what
we
are
where
we
are
today,
I
think
that
all
three
of
those
drafts
need
to
be
mapped,
because
people
come
to
come
to
the
ITF
for
ITF
protocols
and
Technologies
from
different
places,
and
they
may
have
different
security
requirements
that
they
need
to
map
from.
So
I
think
that
we
should
try
and
do
our
best
to
map
from
a
variety
of
them.
Maybe
not
all,
but
at
least
several
I
think
that
nist
and
Denisa
together
is
a
good
Baseline.
I've.
E
Only
done
Anisa
today
next
slide,
please
there
are
so
to
go
to
go
through
how
it's
divided.
Today
there
are
three
different
categories
of
the
of
requirements
that
are
mapped.
The
first
one
is
procedural,
those
requirements.
We
can't
really
do
much
about
we're,
not
that
kind
of
Standards
organization,
and
the
next
is
our
architectural.
E
Now
some
of
the
architectures
are
covered
by
ietf
architecture
drafts,
but
not
all
of
them,
and
some
of
them
relate
to
how
you
build
Hardware,
the
some
of
the
architectural
requirements
so
that
that
obviously
is
not
our
domain
and
again,
those
are
are
flagged,
but
not
mapped
next
slide,
oh
and
then,
of
course,
they're
the
important
ones,
the
technological
requirements,
which
is
what
we
care
about
next
slide,
please
and
getting
ahead
of
myself
right.
E
So
there's
a
bunch
of
of
categories
that
that
are
described
and
and
I've
I've
broken
them
down.
It's
not
that
interesting
to
talk
through
them
at
this
stage.
I
think
the
more
interesting
thing
if
you
want
to
understand
what's
going
on
there
is
to
go
and
look
at
the
draft,
but,
broadly
speaking,
each
of
these
has
a
mapping
into
something
that
we
do.
We've
got
cozy
we've
got
TLS
and
and
oscore
and
dtls
and
Matt
I,
don't
and
quick
I,
don't
think
Quick's
in
there
there's.
E
E
So
right
now
again,
as
I
said
before,
I
only
have
any
requirements.
Mapped
I
would
very
much
appreciate
help
from
other
from
other
contributors
in
looking
at
some
of
the
other
Baseline
requirements
documents
and
trying
to
sort
of
merge
some
of
these
requirements
into
similar
categories,
so
that
we
can
group
together
the
kinds
of
things
that
are
important
in
different
places
and
whether
we
have
any
gaps
that
are
are
present
in
the
existing
Suite
of
ietf.
Technologies.
E
Next
slide.
Please
or
is
that
it.
A
E
Oh
yeah,
oh
there
I
already
said
that.
So,
if
you,
if
you're
interested
in
this
work,
I,
would
very
much
appreciate
your
input
and
I
I.
Think
that
there's
there's
something
that
that
there
is
a
gap
today
in
in
the
ietf,
where
you
know,
if
I,
if
I
came
here
in
and
I
didn't
know
anything
about
what
we
were
doing.
I
would
not
know
where
to
look
for
the
the
information.
E
I
need
to
build
a
secure,
iot
solution
and
I
think
there's
a
big
gap
when
it
comes
to
things
like
information
security
officers
trying
to
understand
whether
they
have
actually
followed
all
of
the
best
practices
and
whether
they're
missing
any
Technologies.
To
do
that
so
I've
run
through
that
very
quickly.
Are
there
any
questions.
H
Hi
there
I'm
Jasper
Panzer
hi.
This
is
my
first
ITF
so
nice
to
be
here
and
thank
you
very
much
for
the
presentation.
So
I
actually
am
the
or
was
the
evaporator
of
what
you
had
on
the
screen
as
the
Etsy
Baseline
security
requirements
for
Consumer
iot.
This
is
also
the
this
is
called
the
European
Standard
en
303645.
A
And
could
you
please
move
a
little
bit
better
to
the
mic?
I'll
sure
I
have
to
remind
you
that
everybody,
but
the
presenter
is
supposedly
to
wear
a
mask.
I
know
it's
it's
difficult,
but
eat
the
mic
with
a
mask.
I.
Think
that's
our
compromise
here.
My.
H
Apologies
yeah,
so
you
mentioned,
there's
a
gap
to
help
the
wider
communities
understand
what
their
requirements
are
and
how
to
implement
those
requirements
in
real
life
on
the
consumer.
Iot
set
I
think
they've
got
this
fairly
well
covered
by
by
Etsy,
so
the
en33605
sets
out
the
requirements
both
on
the
technical
side,
but
also
on
the
organizational
side,
and
then
there
are
two
companion
documents
which
I
have
not
seen
referenced
in
the
document
that
was
shared
for
this
presentation.
H
One
of
those
companion
documents
is
ts103701,
which
is
an
assessment
specification
that
helps
assess
a
device
against
the
requirements
are
set
out
in
the
en
standard
and
the
second
guide.
The
second
document
that's
only
been
published
this
year
in
September
is
an
implementation
guide
and
that's
40
pages
long
with
with
implementation
examples
for
each
of
the
security
requirements
set
out
in
the
main
en
203605
standard,
so
there's
a
whole.
H
A
And
but
before
you
leave
the
mic,
this
last
slide
that
is
presented
here
on
the
screen.
Is
there
on
purpose?
Would
you
have
the
time
this
one
yeah?
Would
you
be
able
to
contribute
and
identifying
these
additional
I
want
to
say
Parts
to
help
Brendan
with
this
book?
Yes,.
H
Of
course,
I'd
be
happy
to
pawn
point
you
to
the
in
the
right
direction
and
and
link
you
to
the
relevant
documents
and
make
introductions
to
to
the
key
offices
needed
in
just
for
a
sake
of
completeness,
the
implementing
guide,
I
references,
TR,
103621
and
that's
all
freely
accessible
without
any
payroll.
Thank.
E
You
so
I
I,
very
much
appreciate
the
comments
and
it's
great
to
hear
that
there's
actually
implementer
guides
appearing,
but
notwithstanding
that
I
I
suspect
that
that
will
not
be
true
of
all
of
the
Baseline
security
requirements.
Documents
that
are
extant
today
and
people
wishing
to
follow
those
other
guides
may
need
some
help.
A
So
if
they're,
there
are
no
no
more
questions
about
this
there's
a
chess
question
we
would
like
to
raise
because
this
document
evolved,
like
you
said
that
twice
significantly
and
from
a
chess
point
of
view,
we
would
be
willing
to
take
into
account
that
we
adopt
this
document.
Okay,
would
you
be
interested
in
having
a
in
room
assessment?
Call
about
that
sure
so,
because
I
try
to
phrase
something
I'm,
not
entirely
sure.
A
A
A
A
So
this
is
an
in-room
assessment.
We
will,
of
course
repeat
that
ask
on
the
iot
Ops
list,
so
everybody
who
is
having
an
opinion
here,
will
we
have
to.
C
A
It
doesn't
show
so
I
will
read
it
out
loud,
so
the
raised
hands
in
total
were
36
and
we
have
33
and
in
favor
in
three
Nays.
Anybody
who
has
an
a
opinion
wants
to
highlight
why
that
doesn't
seem
to
be
a
good
idea
and
there's
no
pressure
on
this.
If
you
want
to
be
silent,
that's
fine.
A
Which
will
I
take
as
being
silent
is
fine
okay,
but
there's
Emmanuel
in
the
in
the
The
Cure
just
C,
so
Emmanuel
you
can
speak
up.
J
Hi
Brandon
and
thanks
a
lot
for
this.
This
effort,
which
I
think
is
very,
very
useful
and
maybe
I
missed
it,
but
you
talked
about
potential
gaps
and
so
I
understand
that
that
there's
you
haven't,
assessed
all
of
these
guidelines,
but
for
the
guideline
you've
assessed
the
most,
which
is
Anissa
I
guess
then
what
would
you
say
is
the
the
the
the
biggest
mismatch
that
you
have
noticed
so
far
or
that
you
expect.
E
So
I'm
I'm
winging
this
a
little
bit
but
I
didn't
see
a
lot
in
the
way
of
onboarding
guidance
and
I.
Think
that
may
be
a
a
bit
of
a
gap
there
I
I,
don't
think
there's
much
like
there's
pretty
good
coverage
overall,
but
I
think
that
might
be
a
missing
link.
Okay,.
E
E
E
A
Which
sounds
to
me
like
a
semi-reliable
commitment
to
contribution
yeah.
A
So
if
that's
not
the
case,
we
will
restate
a
former
working
group
last
working
group
adoption
call
on
the
list
for
this
all
right,
I
think
directly
after
the
ITF
meeting,
and
then
we
go
from
there.
Thank
you
friend
thank.
A
I
see
one
comment
here:
that's
on
the
Nay
side,
which
that's,
why
not
hand
was
raised
and
there's
the
scope
is
not
entirely
clear.
So
you
still
have
a
little
chance
to
get
back
to
that
sorry.
E
I've
run
back,
the
scope
is
intended
to
be
a
mapping
document,
so
this
is
specifically
to
say
there
are
requirements
that
are
provided
by
a
bunch
of
Baseline
requirements,
documents
and
we'll
take
a
selection
of
those.
The
scope
that
I've
defined
today
is
relatively
weak
on
which
requirement
documents.
We
should
adopt
I'm
happy
to
take
input
on
that.
E
Then
it's
a
mapping
from
those
requirements
to
ietf
Technologies
and
if
we
see
any
gaps,
we
should
either
provide
Baseline
requirements
that
are
missing
from
the
existing
documents
or
we
should
highlight
to
working
groups
technologies
that
are
missing
from
the
ITF.
If
we
discover
any
that's
the
scope,
is
that
a
clear
scope.
A
Well,
that's
the
question
was
based
on
the
chat:
I'm,
not
sure
how
in
sync
yeah
the
reply
here,
but
I
think
we
can
move
the
discussion
to
the
list
again
in
the
case
yeah.
Thank
you.
Yeah
I,
just
didn't
want
to
keep
people
that
are
contributing
to
the
chat
out
of
the
loop
I.
Think
it's
important
for
the
Fantasia
yeah,
further
questions
on
the
list
and
still
a
broad
scope.
By
the
way
it
said
okay,
but
moving
on.
So
next
presentation
is
power
of
attorney.
A
L
L
Okay
next
slide,
please
so
power
of
attorney
overview.
You
all
know
about
power
of
attorneys
in
real
life
that
you
can
delegate
some
authority
to
someone
to
to
to
represent
you
at
some
meeting
or
something.
But
here
we
propose
it
in
a
digital
form
where
a
principal
can
sign
a
POA
and
give
it,
for
example,
to
a
device,
and
typically
we
are
looking
into
semi-autonomous
devices
or
entities
that
are
fairly
powerful
and
can
act
on
your
behalf
and
also
the
agents.
L
Then
so
the
POA
is
used
here
to
authorize
these
entities
and
this
identities
they
have
to
have
an
identity
right.
So
it's
not
like
super
small
and
it
is,
they
have
some
identity.
They
typically
have
a
public
key
and
a
private
key
so
that
they
can
be
identified
and
so
on
and
they
act
and
on
behalf
of
the
resource
owner,
that's
called
the
principal
here.
So
we
have
principles
and
agents.
The
POA
is
a
self-contained
document.
This
is
decentralized,
so
it
can
include
detailed
credentials
and
also
expiration
type.
Next,
please
so.
L
Some
of
the
essential
properties
here
is
that
it's
self-contained
and
decentralized,
as
I
said,
so
it
resembles
like
PDP
that
is
used
for
authentication,
primarily
and
but
we
use
here
for
authorization.
Primarily,
you
can
add
some
centralization
into
this
by
having
an
optional
signatory
registry
that
can
store
poas
and
and
sign
them
and
authorize
them
in
another
step.
L
K
Thank
you
Lou,
so
onboarding
it.
It
must
be
administrative,
administratively
scalable,
that's
the
that's
one
of
our
goals,
so
the
site
owner
must
have
a
secure
method
to
to
delegate
the
onboarding
credentials
to
the
subcontractors
and
the
subcontractor
here
or
the
integrator
is
the
one
who
on
the
device.
And
so,
if
we
delegate
the
power
through
our
approach,
then
the
then
the
device
can
onboard
on
behalf
of
the
subcontractor.
K
So
onboarding
should
not
require
all
the
parties
in
the
trust
chain
to
be
online
in
our
case,
and
it
also
doesn't
necessarily
involve
transfer
of
the
ownership,
because
the
owner
here
is
the
subcontractor
and
he
can
onboard
himself
by
using
the
power
of
attorney
next
slide.
Please
yeah.
So
this
is
the
basic
idea
of
what
is
the
power
of
attorney
based
authorization.
So
we
you
can
see
in
the
figure
like
there
are
three
entities,
principle
agent
and
the
resource
server.
So
the
principle
is
the
is
the
subcontractor
in
the
use
case.
K
K
So
here
the
resource
server
can
be
seen,
as
in
the
case
of
onboarding
use
case,
we
can
say
it's
the
Target
Network
on
boarding
controller
so
upon
receiving
the
POA
from
the
agent.
The
resource
server
now
can
grant
the
the
required
required
documents
or
whatever
data
that's
required.
That's
requested
in
the
POI
to
the
agent.
K
So
using
that
data,
the
agent
can
work
on
behalf
of
the
principle,
and
we
also
have
the
signature
registry
to
store
the
poas
and
some
other
metadata
if
it's
needed
it's
an
optional
entity.
Next
slide,
please
Yep.
This
is
our
approach
for
onboarding,
so
we
we
are
trying
to
establish
a
trust
chain
between
the
subcontractor
and
the
device
and
the
target
network,
onboarding
controller
or
Target
Network.
So
this
can
be
done
through
transferring
the
POS
between
these
three
entities.
So
we
have.
K
We
have
two
POS
in
the
case
of
onboarding
use
case,
so
the
first
one
is
from
the
subcontractor
to
the
to
the
device.
So
sorry,
the
first
one
is
from
the
onboarding
controller
to
the
subcontractor
so
that
the
subcontractor
can
now
on
board
on
behalf
of
the
actual
Target
Network
and
another
one
is
between
the
subcontractor
and
the
device
so
that
the
device
now
can
onboard
on
be
on
behalf
of
the
subcontractor,
so
it
can
onboard
itself.
Next.
K
Is
that
yeah,
as
I
mentioned
before
the
ownership
it
can
be
kept
by
the
subcontractor
and
together
we
it?
We
are
trying
to
be
more
scalable
in
an
administratively
scalable
and
more
secure,
and
also
we
can
even
pass
the
authorization
credentials
through
the
inside
the
POA
yeah
next
slide.
Please
Yep!
This
is
the
protocol
flow
for
the
POA
based
authorization
for
onboarding.
K
So
we
have
the
subcontractor
device
and
the
onboarding
component
and
the
certificate
Authority
for
from
the
local
Cloud,
so
the
subcontractor
now
of
in
the
A
and
step
B
are
the
two
power
of
attorneys
as
I
mentioned
earlier.
So
the
a
is
the
onboarding
component,
sending
its
power
of
attorney
to
the
subcontractor,
the
principal
so
that
now
the
principal
gets
the
credentials
or
it's
all
the
rice
now
next
after
that,
principal
now
can
can
now
generates
another
another
POI
to
its
trusted
device.
Now
on
the
device.
K
Now
can
it's
a
device
that
we
need
to
onboard
and
the
device
now
can
onboard
in
C,
C,
A,
C,
A
and
B?
So
it's
it's!
It's
sending
the
POA
along
with
the
other
and
other
device
onboarding
credentials,
and
then
indeed
there
is
a
communication
between
the
certificate,
Authority
and
the
onboarding
component.
It's
basically
nothing
but
the
public
key
certificates
and
then
in
F
the
onboarding
component
upon
successful
verification
and
validation.
K
K
So
the
we
include
the
public
keys
and
the
resource
owner
ID,
which
is
the
ID
of
the
Target
Network,
and
we
also
have,
as
I
mentioned
like
the
expiration
time,
and
we
also
have
the
transferable
parameter,
which
is
quite
important
like
this
is
the
one
as
ulo
mentioned,
we
can
do
multi-level
authorization
or
the
agent
or
the
device
can
actually
transfer
the
POI
to
another
agent
if
the
the
X
in
the
transferable,
if
the
in
that
integer
is
one
two
depends
on
how
many
levels
you
want
next
slide,
please
yep!
K
So
we
POI
can
be
used
as
a
in
General
application,
not
only
for
onboarding.
It
can
also
be
used
for
other
General
applications,
and
we
have.
We
have
built
an
open
source
Library,
so
anyone
can
download
it
and
use
and
also
another
future
work
is
to
build
a
Docker
image
for
that
and
another
interesting
work
is
to
integrate
it
with
oil.
We
have
a
a
publication
on
that
next
slide.
Please.
K
A
Yeah,
there's
a
secure
forming
up
and
I'll
give
you
first.
C
K
B
So
yeah
thanks
so
I,
so
you
said
that,
like
the
from
the
very
beginning,
I
got
a
strange
feeling
that
I
heard
that
terminology
already
so
that's
resource
server
that
really
similar
to
the
auth
right.
So
and
in
the
end
you
said
that
we
need
to
integrate
with
the
oos.
So
I.
Just
don't
really.
Can
you
explain
how
that's
really
different
from
the
OS
and
what
should
be
the
exactly
with
the
integration
but.
L
Some
of
the
properties
we
mentioned
earlier
is
that
it's
like
the
time
difference.
The
POA
is
something
that
you
sign
off
beforehand
and
it
could
be
valid
for
a
longer
period
of
time
like
days
or
weeks,
depending
and
and
it's
also
sent
to
an
entity
that
has
its
own
identity
and
can
do
the
public
key
or
a
private
key
authentication
and
authorization,
and
it's
that
we
can
do
it
in
several
steps
also.
So
the
whole
point
here
is
to
be
able
to
get
scalable
onboarding
by
delegating
it
to
subcontractors,
for
example
in
mining
industry.
L
E
Hi
I
was
wondering:
I
actually
have
two
questions
and
a
comment.
So
first
the
comment
the
key
are:
the
signatory
registry
looks
to
me
like
it's
got
substantial
overlap
with
with
work
in
skit,
so
you
might
want
to
check
out
the
skit
working
group,
the
second,
the
the
question.
The
first
one
is.
Can
you
highlight
for
me
what
the
overall
differences
are
between
this
and
key
delegation
with
key
utilization.
E
G
E
E
L
Yeah,
but
it's
it's
the
authorization
part
here
that
it's
the
focus
really,
if
you
like
pki,
it's
it's
more
on
the
authentication
and
delegating
the
full
thing
right.
So.
L
No
okay,
we
use
you
can
use
pki
for
the
public
and
private
keys
that
are
used
to
sign
and
and
direct
these
poas.
So
the
POA
is
directed
to
an
agent
based
on
the
public
key
of
that
agent
or
that's
part
of
the
identity
of
the.
E
Okay,
I
guess
the
final
question
I
have
is:
how
are
you
handling,
revocation,
when
your
sub
contractor
does
something
nasty
and
you
need
to
get
rid
of
them.
L
Replication
of
the
POA,
that's
like
storing
it!
Well,
that's
not
yet
in
scope,
right.
L
Is
always
a
very
hard,
it's
a
good
question
really
hard
in
decentralized
systems.
So
how
do
you
ensure
that
if
you
revoke
it
that
it's
not
still
residing
somewhere,
the
POA
repository
adds
some
centralization
to
the
concept
and
improves
the
possibility
to
revoke,
but
that's
the
best
answer
we
have
right
now.
Okay,
thank
you
for
the
study.
Thanks.
L
G
Eric
so
one
of
the
things
I'm
trying
to
map
out
in
my
head
and
I
can't
quite
do
it
on
the
Flyers
sort
of
the
flows
here
compared
to
something
like
the
the
fighter
device
are
onboarding
right
because
it
has
some
similar
things,
but
I
think
it
would
be
very
useful
to
sit
down
and
sort
of
see.
Okay.
How
do
these
things
actually
relate?
Because
it's
not
quite
it's
not
delegation
in
this
sense,
but
it
is
sort
of
this
handoff
of
here.
I
have
something
that
was
manufactured.
G
L
Yeah,
we
have
looked
into
Fido
and
it
seems
that
the
main
focus
there
is
to
through
the
supply
supply
chain
and
changed
ownership
and
all
the
way
to
onboarding
at
this
final
site
and,
as
we
said,
we're
not
necessarily
demanding
a
change
of
ownership.
They're,
also
based
on
the
Rendezvous
server
yeah,
to
handle
this
so.
M
Hello,
eskodak
I
just
heard
you
were
using
Json
web
token,
I
think
and
that
kind
of
was
ringing
a
bell
in
my
mind,
because
I've
been
working
on
the
specification,
it's
not
a
public
one,
but
one
where
we
defined
the
seaboar
web
token.
So
it's
like
the
compact
version
of
that
for
for
a
similar
purpose,
it
was
not
specifically
onboarding,
but
it
was
for
a
commissioning
entity
to
manage
iot
devices
in
a
commercial
Network
for
a
specific
domain.
M
So
the
commissioner
would
get
a
token
basically
renting
certain
rights
of
management
for
limited
duration,
so
it
was
all
encoded
in
the
web
token.
So
in
that
sense,
that
sounds
similar
and
I
think
the
use
case
might
be,
you
know
very
common,
let's
say,
because
it
came
up
from
industry
requirements
I'm,
not
sure,
yet
what
the
relation
is
with
with
onboarding.
So
it
seems
like
slightly
different
managing
from
from
delegating
the
onboarding
part
to
a
subcontractor,
but
yeah
I
won't
think
about
that.
So
just.
L
M
F
Hi
Michael
Richardson,
so
I
noticed
I
took
a
quick
look
at
your
draft
draft
and
I
noticed
you
cite
the
Intel
stuff,
but
not
the
Fido
stuff,
which
is
essentially
an
evolution
of
them.
Intel
has
some
interesting
and
potentially
bogus
IPR
on
in
their
stuff.
F
F
I
guess,
I'll
I'll
say
you
need
please
come
and
look
in.
The
animal
working
group.
Esco
here,
for
instance,
is
working
on.
As
you
said,
the
constrained
voucher
format,
which
is
cozy
signed
seabor.
We
also
have
Jose
signed
Jason,
as
well
as
the
original
CMS
sign
Jason.
F
In
addition
to
that,
we
have
a
mechanism
by
which
devices
can
be
onboarded.
Offline
offline,
off-boarded,
I,
don't
know,
but
the
conception
here
is
that
a
commissioner,
a
person
would
in
fact
wander
into
in
their
reference
thing
into
the
basements
of
newly
constructed
homes,
for
instance,
which
have
no
internet
and
have
no
LTE,
because
it's
the
basement,
my
office
is
in
the
basement.
I
have
no
LTE
at
my
desk
and
would
onboard
the
device,
and
the
idea
is
that.
F
Actually
we
really
do
want
to
minimize
round-trip
times
because
they
actually
represent
commissioner
guy
going
up
and
down
the
stairs
with
his
device
so
that
that's
that's
a
whole
Space
of
things
that
there
and
so
to
me
it
sounds
like
you've
kind
of
reinvented
three
or
four
wheels
here
and
I
I
I
I
I'm,
not
sure
that
there's
a
reason
for
it
to
be
gratuitously
different,
so
I
would
encourage
some
convergence
of
file
formats,
even
if
you
can't
get
all
the
semantics
the
same.
F
Okay,
as
Elliot
said
earlier,
there
are
19
different
ways
of
doing
things,
but
we
don't
have
to
have
19
different
file
formats
and
I.
Think
that's
really
important
and
and
also
there's
an
OPC
UA
mechanism
and
it's
mostly
Trust
on
first
use.
However,
they
have
some
interest
in
doing
something
more
or
some
of
them
do,
and
so
that's
particularly
important.
Finally,
I
don't
really
understand
what
what
is
it
when
you
say,
there's
no
transfer
of
ownership.
F
L
Okay,
that's
also
a
lot
of
things,
but
thanks
a
lot
for
the
input
where
we're
gonna,
look
and
I
hope
we
get
the
minutes.
So
we
can
remember
all
the
related
Technologies
I
I
try
and
do
one
by
one.
The
Intel
thing,
I
I,
agree
that
if
we're
into
consumer
market,
for
example,
there
is
probably
no
big
need
for
POA
you're
fine
with
that
the
original
manufacturer
has
the
centralized
server
to
keep
track
of
the
device
through
the
supply
chain
and
all
the
way
into
onboarding.
L
We
have
gotten
our
requirements
from
industry.
We
have
talked
to
like
mining
industry,
for
example,
and
that's
where
they
have
the
case.
They
they
don't
really
want
to
trust
the
original
manufacturer.
They
have
trust
chains
between
subcontractors
and
main
site,
and
they
want
to
see
this
way
of.
How
can
we
onboard
things
in
a
scalable
way?
So
that's
where
we
are
it's
more
industrial
applicability
here,
I
would
say
and
then
transfer
of
ownership.
L
F
So
I
think
that
I
think
that
what
you're
telling
me
is
that
when
I
come
to
visit
your
home,
you
would
like
to
allow
my
phone
on
your
network
yeah,
but
you
don't
want
to
own
my
phone
right
and
that's
the
same
model
so
really
in
some
sense.
This
is
not
about
onboarding.
This
is
about
access
control
to
that
thing
and
about
relationships
of
network
and
I
wish
we
could
so
it
sounds
to
me
like.
F
Actually
we
have
a
new
thing
and
that
we
need
a
new
term
not
on
not
onboarding,
and
that
that's
actually
I
think
where,
where
your
document
and
your
conceptual
of
power
of
attorney
as
of
that
way
as
a
mechanism
is
I,
think
actually
a
really
powerful
conceptually
right.
So
you
know-
maybe
maybe
POA
is
the
right
term,
or
maybe
it's
a
some
other
word
powering
of
attorney
or
something
like
that.
But
so
so
that
sounds
like
a
really
cool
thing
that
that
you
have
some
delegation,
but
not
a
full
transfer.
F
L
G
A
And
thank
you
so
what
I
can
hear
do
you're
always
welcome
to
report
back,
but
I
had
two
target
zones
here
from
the
audience.
One
of
them
was
a
Content
relationship
to
Something
in
the
the
newly
formed
skit
working
group
and
even
also
echoed
in
the
chat
by
participants,
is
maybe
presented
oauth
and
and
talk
about
that
there,
which
parts
would
go
there
for
the
protocol
wise
and
what
of
the
concepts
for
premature
so
basically
in
advance,
providing
these
powers
to
other
people
so
to
speak.
A
J
N
You,
okay
good.
This
is
sort
of
a
yesterday.
I
had
the
very
little
limited
time
slot
and
so
I
wasn't
really
able
to
go.
Walk
you
through
the
details.
So
what
I'm
planning
to
do
is
to
go
through
one
of
the
scenarios
and
describe
some
of
the
details
to
give
you
a
an
idea
what
we
are
trying
to
do
here,
I
focus
on
the
iot
onboarding
scenario.
N
Although
for
us
this
is
probably
the
the
confidential
Computing
scenario
is
what
we're
really
after,
but
I
think
the
iot
onboarding
scenario
just
fits
better
and
it's
also
described
in
a
document.
Okay,
it's
actually
three
documents.
So
here's
the
starting
point
next
slide.
The
starting
point
is
of
all
of
this.
The
device
puts
up
and
does
the
initial
attestation,
which
is
something
the
rats
group
has
been
working
on
for
quite
a
while
and
in
our
implementation.
N
If
you
download
the
trusted
firmware,
M
and
a
what
it
does
is,
there's
a
bootload
that
we
use
and
you
put
for
m-class
devices.
It
creates
a
hash
over
different
firmware
images
like
the
bootloader
itself
and
if
there
are
multiple
stages
of
bootload
us,
obviously
multiple
times
the
firmware
images
and
so
on
and
so
on,
and
then
this
information
from
the
bootloader
as
it
relinquishes,
control
and
passes
it
over
to
the
firmware
image
or
the
next
stage.
Bootloader.
N
It's
basically
passed
up
finally
to
the
attestation
service,
which,
when
this
attestation
service
is
called
to
provide
the
e-token,
it
will
do
so
and
in
the
document
we
call
this
the
platform
at
the
station
token
to
distinguish
it
from
the
other
talk
which
we
newly
Define,
namely
the
key
attestation
token
I,
had
to
give
it
a
name
that
was
the
best
one
we
came
up
with,
and
this
platform
attestation
token
with
the
software
measurements
inside
them,
as
as
Claims,
can
be
used
to
determine
on
whether
the
software
running
on
the
device
actually
has
been
tampered
with,
which
is
quite
important
for
this
use
case,
because
we
want
to
make
sure
that
the
key
at
the
station
service
is
actually
still
operating
in
the
way
it
does
intended
in
the
in
the
document.
N
N
So
when
it
comes
to
the
stage
where
the
device
actually
does
stay
the
onboarding
step,
it
runs
a
DLS
client
that
wants
to
talk
to
the
to
the
TLs
server
with
and
we've
just
spoken
about,
onboarding,
and
there
are
obviously
different
options
available
which
option
you
choose
is
immaterial
to
this
discussion.
N
So
in
the
setup
the
iot
device
is
the
DLS
client
as
the
tester
and
the
onboarding
server
is
the
server,
and
so
the
client
wants
to
send
the
evidence
to
the
server
in
the
terminology
of
the
rats.
Working
group
there's
also
assumes
the
background
check
model
where
the
relying
party
talks
to
the
verifier
to
get
the
attestation
result
there's
or
there
also
other
models
such
as
the
passport
model,
which
is
which
I
don't
go
through
and
it's
not
described
yet
in
a
document
either
so
we'll
skip
that
next
slide.
N
So
here's
how
it
starts,
since
one
of
the
documents
listed
on
the
first
page
is
about
the
extension,
the
newly
defined
extension
to
the
TLs
handshake
in.
If
you
define
some
new
functionality
in
TLS,
you
always
have
to
do
this
initial
negotiation
in
the
client,
hello
and
either
server.
N
Heller
or
in
the
encrypted
extension,
and
that's
what
this
one
and
two
indicates
here
so
there's
a
new
extension
defined,
which
it's
called
if
for
this
purpose,
is
called
evidence
proposal
because
it
passes
evidence
around
and
communicates
what
functionality,
what
attestation
technology
the
client
supports,
and
the
idea
is
that
you
can
support
different
attestation
Technologies,
since
they
are
just
different
ones.
N
So
we
live
in
the
market
today
and
to
sort
of
Select
something
what
it
also
does
is
it
needs
to
pass
a
nons
to
the
client,
because
that
nuns,
if
you
follow
the
rats,
work,
this
nonsense
included
in
the
in
whatever
the
evidence
produced
by
the
device
to
guarantee
freshness
of
the
produced
data,
so
that
needs
to
come
along
as
well,
and
the
green
box
shows
that
the
nonce
needs
to
come
from
somewhere,
namely
typically
from
the
verify,
either
in
real
time,
or
it's
obtained
earlier
up
front
in
a
in
a
batch
of
nonsense
that
it's
really
an
implementation
detail.
N
Okay,
so
that's
the
initial
phase
next
one
then
the
the
TLs
client
needs
to
obtain
the
evidence
from
the
attestation
service,
and
that
happens
in
and
the
next
slide
explains
the
more
complex
structure,
but
it
requests
this
sort
of
bundle
of
tokens,
one
being
the
platform
attestation
token
and
the
other
one.
The
key
at
the
station
token
and
the
key
at
the
station
token
requires
that
you
have
bind
a
new
public
private
keeper.
N
To
that
token,
that's
what
the
already
the
name
kind
of
indicates
that
this
is
going
to
happen.
So
at
some
point
in
time
you
need
the
TLs
client
needs
to
create
what
we
referred
here
as
an
identity.
Key
it's
just
a
key
pair
and
and
the
private
key
obviously
needs
to
stay
on
the
device
and
that's
what
the
platform
attestation
token
ensures
that
this
there's
no
sort
of
compromise
in
that
in
that
attestation
service
to
expose
that
private
key.
So
it's
it
stays
there.
N
The
platform
attestation
functionality
is
unmodified
because
that's
a
small
service
running
on
the
device,
and
so
the
request
in
the
green
box
essentially
says
give
me
this
bundle
and
I
give
you
the
nuns
that
we
just
obtained
on
the
previous
slide
and
pass
in
this
identity
key
the
public
key
part
of
it
as
input.
Okay,
next
slide.
N
So
this
is
then
the
the
bundle-
and
it
consists
of
these
two
other
tokens
which
are
links
linked
together.
They
are
linked
wire,
the
nuns,
the
they're,
not
they're,
obviously
different
ways
to
link
them.
You
could
also
Define
like
design
it
slightly
differently,
that's,
but
we
came
up
with
because
we
wanted
to
use
our
existing
attestation
service
and
and
basically
keep
it
unmodified
and
the
linkage
happens
via
the
use
of
the
nuns
which,
in
this
case
the
nonce
in
the
path
is
the
hash
of
the
identity.
N
Key
used
in
the
cut
sounds
a
little
bit
complicated.
That's
why
I
created
a
picture
and
showed
this
with
the
errors
here
and
the
non's
in
the
cut.
The
key
attestation
token
is
the
non-stabus
provided
by
the
TLs
server
and
actually
by
the
verifier.
Okay.
Next
slide,
so
somehow
the
client
also
has
to
send
in
this
result
to
the
server
and
it
uses
the
certificate
message
very
much
in
style
of
what
the
raw
public
erfc
in
TLS
did.
N
The
wrote
that
RFC
allows
you
to
rip
or
convey
different
payloads
in
a
certificate
message,
not
just
the
next
five
for
nine
certificate,
so
that
there's
a
registry
defining
a
couple
of
different
things,
so
that
gets
sent
over
there
and
next
slide
and
and
of
course
the
client
also
needs
to
demonstrate
possession
of
the
private
key
created
this
to
this.
N
Our
related
to
this
identity
key-
and
this
is
done
using
the
certificate,
verify
message,
and
so
that
signature
is
uses
the
I,
this
identity
key
the
private
key
part
of
it
and
it's
a
sort
of
regular
DLS
operation
in
some
sense,
okay,
next
slide.
N
And
finally,
of
course,
the
server
needs
to
contact
the
verifier
to
get
to
get
the
attestation
reside
back
because
it
as
a
relying
party
cannot
really
evaluate
what
is
India.
That's
the
whole
sort
of
point
of
having
to
verify
in
the
first
place.
This
is
sort
of
like
straight
out
of
the
rats
architecture,
so
this
step
happened
and
then
the
whole
dance
is
if
positive.
If
the
at
the
station
result
is
positive
and
and
the
public
key
ik
public
key
is
returned.
Obviously
that
was
everything
then
was
successful.
N
Otherwise,
The
Exchange
will
be
aborted.
Okay
next
slide,
I
think
that's
actually
the
last
yeah.
So
what's
the
status
of
this
so
I
mentioned,
there's
the
confidential
Computing
use
case,
which
is
kind
of
mirrors.
What
I
just
explained
in
the
sense
that
the
server
is
attested
to
the
client
rather
than
the
other
way
around,
which
is
useful
for
cases
where
you
want
to
upload
the
compute
workload.
N
Do
some
confidential
Computing
platform
and
obviously
want
to
be
assured
that
the
platform
you're
uploading
your
code
to
sort
of
has
certain
properties
we've
been
doing
some
prototyping
effort
and
the
links
are
on
the
next
slide
and
they
are
supported
and
sponsored
by
the
confidential
Computing
Consortium.
B
N
N
So
here's
obviously
the
documents,
but
maybe
more
interesting,
is
the
is
the
code.
If
you
want
to
try
this
out,
it's
obviously
very
early
stages
and
the
links
will
you
know
hopefully
in
the
near
future,
will
be
sort
of
made
available
on
the
confidential
Computing
website
sort
of
for
easier
consumption
and
integration
into
into
some
of
the
other
projects
there,
and
if
you
would
like
to
try
it
out
and
and
need
help
or
need
some
guidance.
N
Let
us
know
would
be
happy
to
to
walk
you
through
and
specifically
talk
about
some
of
the
confidential
Computing
use
cases
with
you.
That's
all
I
had.
A
Thanks
we've
already
thrown
the
line,
I
have
to
make
a
logistical
comment
that
it's
just
a
small
reminder
that
everybody
in
the
room
is
required
to
wear
a
mask
at
all
times
unless
drinking
or
taking
a
small
pause
I've
witnessed.
It
is
not
always
the
case
here
in
this
room
and
well
for
this
small
reminder
and
go
ahead.
G
Eric
not
Mark,
so
so
let
me
try
to
Echo
back
what
I
think
you
said
so
we're
doing
TLS
with
client
certificates.
It's
just
that
the
certificates
are
a
bit
special
right.
They
have
a
bit
more
things
in
them
and
then,
but
if
that's
the
case
well,
one
thing
I
didn't
quite
understand:
is
this
identity
key
or
Associated
certificate?
When
does
that
actually
change?
Is
that
actually
a
a
basically
a
long-term
identity
of
that
that
device
of
that
client?
Or
is
it
something
that
changes
more
frequently.
N
Very
good
question:
Eric
yeah,
so
it's
actually
an
ephemeral
sort
of
an
ephemeral
key
in
that
sense,
and
unlike
regular
client-side
authentication,
where
you
would
typically
have
the
ca.
The
certification
Authority
create
that,
for
you
like
in
an
iot
classical
iot
setup,
you
would
have
that
pre-provisioned
up
front,
maybe
during
the
factory
or
using
some
other
onboarding
protocol,
or
so
this
one
is,
is
not
signed
by
the
ca
it
is
actually
signed.
N
And
if
you
go
back
a
few
slides
to
this
diagram,
it's
actually
signed
by
a
key
that
is
available
to
the
attestation
service.
So
maybe
I
should
have
pointed
this
out.
This
kind
of
makes
it
different
to
a
regular
certificate.
So
in
that
sense,
because
it's
it's
just
a
different
kind
of
a
different
model,
the
security
comes
from
the
fact
that
the
assumption
is
that
the
private
key
of
this
newly
created
identity
key
cannot
be
exposed,
and
this
attestation
service
is
part
of
the
trusted
Computing
base.
N
N
In
in
for
the
onboarding
case,
you
like
run
it
as
often
as
you
do
need
to
do
on-boarding
in
the
in
the
confidential
Computing
case.
You
would
do
it
every
time
you
upload
some
new
or
contact
the
the
platform
and
want
to
sort
of
interact
with
your
compute
platform.
N
G
N
Indeed,
if
you,
if,
which
is
something
we
didn't
describe
there
so
like,
if
you
talk
to
the
device
management
server,
it
I
think
it
would
make
sense
to
also
use
the
mechanism.
Because
then
you
can
be
reassured
that
the
artist
you
would
pass
of
course,
the
platform
at
the
station
token
along
as
well,
and
so
you
would
see
if
something
has
changed.
So
that
would
be
useful
as
well.
N
But
we
didn't
talk
about
sort
of
like
the
next
steps,
but
you're
right,
yeah,
okay,
and
the
reason
why
we
ditched
this
into
the
TLs
exchange
is
simply
because,
if
you
want
to
establish
you,
you
may
want
to
establish
a
secure
Channel
anyway,
and
so
tying
the
the
attestation
information
with
the
secure
Channel
establishment
appear
to
make
sense
to
us,
rather
than
sort
of
leaving
it
totally
separate.
I
Dave
Taylor
two
comments,
so
first
you
mentioned
that
the
covers
the
background
check
and
not
yet
the
passport
model.
I
think
the
background
check
is
the
one
that's
obviously
relevant
here.
If
you
never
do
the
passport
model
in
your
document
or
whatever
that
might
be
okay
background
check
is
for
onboarding.
The
point
is
you're
trying
to
get
the
device
to
test.
I
If
the
device
is
not
on
something,
then
it
may
have
no
connectivity
to
a
verifier
anyway,
and
so
the
only
time
the
passport
might
be
relevant
is,
if
you
didn't
care
about
freshness
and
so
I'm
going
to
say
that,
maybe
we
don't
care
about
that
case.
So
if
you
don't
get
to
that
I'm
saying
that's,
probably
okay,
however,
my
other
comment
is
back
on
slide.
Four.
You
explained
that
the
onboarding
flow
that
you're
looking
at
is
where-
and
it's
on
this
slide
too.
That's
what
the
device
is.
I
I
Where
say
your
onboarding
server
is
a
phone
app
and
the
device
has
a
separate
SSID
that
advertises,
and
so
the
phone
app
connects
to
the
thing
on
board's
a
thing,
and
so
my
question
is:
have
you
looked
at
or
maybe
you
should
look
at
the
attestation
tested
to
OS
when
it's
the
server
that's
trying
to
attest
to
the
client?
You
know
where
the
the
the
TLs
client
and
server
in
the
other
direction-
and
that
is
just
as
interesting
and
still
the
background
check
model
would
apply
there.
I
So
I
would
suggest
rather
than
worrying
about
the
passport
model
anytime
soon,
I
would
rather
worry
about
adding
in
the
other
direction
too,
in
the
same
document.
So.
N
That's
that's
a
good
find
yeah
I,
the
iot
onboarding
model
I.
What
I
had
in
mind
was
the
experience
with
the
fighter
device
onboarding,
which
was
mentioned
earlier.
I
Which
work
exactly
what
is
this
one
and
it's
a
different
set
of
flows,
I
think
ocf
uses
the
opposite
flow
and
so
out
of
each
iot
ecosystem,
each
one
has
its
own
variation
of
flows
and,
like
half
of
them
are
one
half
of
the
other
one.
So
both
of
them
are
interesting
and
your
draft
is
my
flight.
So
thanks.
O
Because
woman,
a
quick
question,
you
gave
some
rational
for
doing
this
in
a
GLS
handshake.
No
one
problem
here,
maybe
that
the
JLS
connection
can
go
on
for
a
long
time.
In
particular,
dtls
connections
tend
to
do
that.
What
do
you
do
when
you
need
more
freshness
during
the
course
of
this
connection?.
N
So
you
specifically
refer
to
like
the
issue
that,
if
you
have
a
DLS
connection
ongoing-
and
you
want
to
re-run
this
step
without
tearing
down
the
connection,
so
there's
the
the
both
tank
authentication
possibility-
which
of
course
we
didn't
describe
yet,
but
that
only
works
from
the
server
side
like
the
server
asking
the
client
to
do
this
and
not
the
other
way
around.
So
so
yeah.
N
It's
a
good
question
on
whether
whether
it's,
whether
there's
a
need
to
to
basically
do
this
saying
an
existing
connection
and
not
dominate
the
existing
connection,
which.
K
N
N
N
Yeah
yeah,
okay,
I,
will
probably
have
to
talk
to
you
about
this
use
case.
Yeah.
Could
thanks
a
lot.
Thank.
A
You
yeah
thank
you
and
Carson
yeah,
probably
close
to
the
mic.
A
O
Hi,
no
for
something
completely
different,
actually
not
that
different,
because
what
I'm
going
to
talk
about
in
part
looks
very
similar
to
what
we
have
been
talking
about,
but
I
want
to
quickly
talk
about
the
airwig
working
group.
O
when
this
was
created,
and
the
reason
was
that
we
thought
we
probably
need
some
informational
documents
on
implementing
constraint,
node
networks,
because
the
standards
on
themselves
are
maybe
not
enough,
and
this
working
group
was
reasonably
productive.
It
has
six
rfcs
out
there
I'm,
citing
to
hear
the
terminology
I've
seen
that
has
turned
out
to
be
very
useful
and
the
using
TCP
and
iot
RFC.
Both
are
informative
documents.
They
are
not
setting
any
standards
or
anything,
but
they
just
explain
things
and
there
are
other
rfcs
on
Energy
Efficiency
next
slide.
O
So
right
now
Eric
has
one
document
in
auth
48..
This
is
just
a
companion
document
to
one
of
the
earlier
documents
that
describes
how
to
do
minimal
Ike,
and
this
describes
how
to
do
minimal,
esps
or
both
are
just
informational.
All
these
things
you
can
leave
out
and
you
still
have
a
valid
ipsec
implementation.
O
There
is
one
document
in
isg
that
discusses
curve
representations.
How
do
you
convert
between
wire
stress
and
AdWords
and
Montgomery,
and
so
on?
Which
really
doesn't
belong
here
at
all?
But
it's
also
outside
of
the
scope
of
what
I'm
trying
to
talk
about,
and
there
are
two
active
drafts.
O
One
is
re-spin
of
7
to
28,
which
is
what
I'm
interested
in
specifically
and
there's
also
another
draft
that
is
providing
some
information
about
comparing
security
protocols.
O
So,
let's
talk
about
those
two
active
drafts,
seven,
two.
Seventy
two
Twenty
Eight-
you
may
have
run
into
that.
In
particular,
if
you
heard
about
people
targeting
class
one
or
class
two
devices,
this
terminology
was
created
in
in
that
document
or
documented
in
that
document,
and
there
is
a
72
or
28
bits
that
both
expands,
the
the
set
of
classes
offered.
So
on
the
bottom
right
of
this
slide,
you
see
classes
of
power
supply
which
are
sometimes
very
useful.
O
When
you
discuss
devices
and
some
classes
need
expanded
ranges,
so
the
the
top
right
is
trying
to
go:
Beyond
class,
202,
class,
3
and
so
on.
So
this
is
an
a
document.
That's
that
has
been
considered
useful
by
people.
It's
pretty
well
cited,
so
we
want
to
complete
that
next
slide
and
the
other
one
is
the
airwig
security
protocol
comparison.
O
A
couple
of
people
have
sat
down
and
and
looked
at
message
sizes
for
various
configurations
of
security
protocols
and
that
maybe
not
the
the
most
important
information
that
you
need
in
designing
your
security
systems,
but
in
the
end
of
course,
you
have
to
make
sure
that
you
actually
can
send
these
messages.
So
it's
useful
to
have
this
information
available
and
there's
also
energy
now
to
renew
this.
O
The
next
slide.
Please.
O
So
Eric,
as
a
working
group
is
11
years
old
and
I
have
a
personal
rule
that
I
never
do
anything
for
10
years,
at
least
not
the
same
time
for
more
than
10
years.
O
So
yeah
this
working
group
is
just
running
out
of
steam.
It's
original
purpose
is
fulfilled.
People
know
how
to
build
iot
systems
with
idea
protocols
these
days.
So
there
are
just
these
two
Children
of
the
working
group
that
really
need
foster
parents
now
and
we
looked
around
and
somehow
thought
about
iot
apps.
O
Well,
most
of
the
work
on
these
documents
is
done.
So
it's
not
going
to
load
down
this
working
group.
Iot
Ops
is
actually
chartered
to
write
informational
documents
about
iot.
O
Well,
maybe
not
exactly
these
two
documents,
but
well
a
few
close
your
eyes
slightly.
Then
then
it
looks
like
it.
It
fits
so
this
would
be
an
easy
way
to
to
get
the
documents
out
of
a
working
group-
that's
kind
of
non-functional
at
this
point
in
time
and
and
complete
them
in
a
reasonable
amount
of
time.
O
So
I
wanted
to
get
some
attention
to
these
two
documents,
in
particular,
of
course,
to
seven
to
28
bits
which
we
really
want
to
complete
within
the
next
few
months
and
ask
whether
this
working
group
would
be
interested
in
having
this
in
in
their
portfolio.
O
Obviously,
the
the
ads
have
to
agree
with
that
or
the
isg
has
to
agree
with
that,
because
the
charger
is
a
contract
between
the
working
group
and
the
isg,
but
yeah
I
think
it
would
fit
very
well
and-
and
Brendan's
document,
for
instance,
is
quite
similar
to
other
things
we
have
done
in
Arabic.
So
this
this
sounds
all
very
fitting
to
me.
A
So
I'm
just
preparing
through
two
comments
from
the
chairs.
First
of
all,
so
yeah
we
have
to
our
ID
is
gone,
so
there
is
no
direct
feedback
from
him
and
we'll
get
you
through
the
mic.
First.
P
Eric
Klein
responsible
area
director
for
elwig,
yeah
I,
know
I
have
to
dispatch
the
curve
document
and
then
my
intention
was
to
unless
there's
new
energy
that
shows
up
in
eloig
was
to
close
it
down.
So
I'm
I'm
happy
to
support
moving
these
documents
to
iot
Ops.
P
If
people
want
to
do
it
here,
if
people
want
to
renew
energy
and
no
way
we
that's
I,
I
can
certainly
keep
it
open,
but
there's
been
not
a
whole
lot
of
energy
there
for
a
while,
as
you
said
so,
I
can
Warren
and
I
had
some
discussion
about
about
this,
but
I
don't
think
we
reached
a
conclusion.
We
were
pressed
for
time
in
that
conversation,
so
anyway,.
N
Constant
I
wonder
whether
it's
like
elbeek
ran
out
of
steam,
but
maybe
it's
not
because
of
the
the
working
group,
but
also
with
the
content
of
the
working
group.
Right
like
nobody
was
interested
in
the
document
other
than
the
authors.
O
Well,
that's
a
matter
of
assessment,
of
course,
but
it's
really
hard
to
work
in
a
working
group.
Whether
a
group
chairs,
don't
answer
your
mail,
that's
in
challenge,
so
that
may
have
slowed
us
down
a
little
bit
more.
Of
course
it's
also.
These
are
not
the
most
important
documents,
but
they
are
still
useful
documents
to
have
around
so
yeah.
The
it's
not
like.
Everybody
is
skewing
up
to
make
comments
on
these
documents,
but
we
should
still
finish
so.
A
So
before
everybody
is
like
like
running
out
of
the
room,
because
I
have
one
minute
left
at
the
bottom
of
the
oh
I'm
gonna
do
another
poll
for
the
people
in
this
meeting.
If
they
think
the
terminology
of
this
kind
could
be
completed
here
in
iot
Ops,
which
of
course
is
just
a
litmus
test.
I
think
we
have
to
really
check
with
the
charter
and
the
chairs,
and
it
is
if
that
fits
so
I'm.
A
And
again,
that's
a
litmus
test.
You
can
really
only
go
forward
if
you
understand
that
the
charter
and
corresponding
handing
off
and
the
two
ads
agree.
A
Let
me
give
it
this
five
more
seconds,
otherwise
we
are
over
time
and
I.
Think
I
can't
count
so
I'm
ending
this,
so
we
have
in
the
end,
32
votes
and
30
of
those
were
in
favor
and
two
were
an
A,
so
that
looks
like
a
in-room
preference
and
therefore
we
will
bring
this
to
the
corresponding
IDs
and
we'll
give
feedback
to
the
rest.
And
that's
a
charity.
A
Yeah,
so
thank
you,
everybody,
that's
basically
minus
minute,
minus
one
here
for
an
iot
drops
I
hope
to
see
you
again
soon
have
a
fine
day
and
let's
continue
those
discussions
on
the
list.