►
From YouTube: IETF-SCITT-20230508-1500
Description
SCITT meeting session at IETF
2023/05/08 1500
https://datatracker.ietf.org/meeting//proceedings/
B
B
D
B
Okay,
perfect
yeah
I
think
we
should
get
started.
I
would
take
some
notes
as
well
as
anyone
else
has
a
chance
to
take
some
notes.
That
would
obviously
be
fantastic,
but
I
will
try
to
do
my
best.
B
So
for
today's
meeting
we
want
to
talk
about
a
few
things.
First
of
all,
we
had
a
little
bit
of
a
break
to
find
out
what
the
meeting
slot
should
be,
and
we
ended
up
with
the
meetings
that
we
had
before
so
a
little
bit
of
detour.
But
here
we
are
the
topics
as
John
sent
around
already
in
the
email
to
the
list.
B
We
wanted
to
talk
a
little
bit
about
this
topic
and
specifically
following
up
on
the
discussions
we
had
a
few
months
ago
on
the
mailing
list
about
bits
in
general,
which
we
unfortunately
didn't
conclude.
I
re-read
the
mailing
this
discussion
and-
and
there
were
a
bunch
of
good
comments,
but
no
real
conclusion,
so
we
we
need
to
make
a
step
forward
on
this.
B
We
also
want
to
talk
about
the
hackathon
as
a
preparation
for
the
next
IDF
meeting
to
work
on
some
like
we
did
at
the
last
hackathon
work
on
running
code
and
to
move
that
forward,
and
then
we
also
want
to
create
an
agenda
item
for
the
next
meeting
for
the
next
week's
call.
So
I
can
also
make
the
announcement
and
update
the
meeting.
Invite
I
I
think,
and
we
can
discuss
that
later.
I
think
registration
policy
would
be
a
good
topic
to
make
some
progress
on
there
as
well.
B
Okay,
any
other
topics
you
guys
want
to
discuss.
E
Say
that
since
it's
been
a
long
time,
I
think
it
would
be
good
and
I
think
there's
been
some
progress
made
in
the
architecture
or
whatever
the
editor's
meeting
regarding
the
I
just
forgot.
What
I
was
gonna
say,
oh
from
the
hackathon,
the
the
things
that
I
thought
were
important.
E
There
were
the
fact
that,
if
we're
going
to
have
a
receipt
or
some
way
for
the
for
the
public-
or
you
know
the
user
groups
to
check
on
the
Integrity
of
the
of
the
log,
the
append
Only
log,
then
there
needs
to
be
some
additional
information,
additional
information
that
that
varies
based
on
architectural
law
and
that
we
want
it
to
be
variable.
So
that
was
one
of
the
seems
like
loose
items
from
that
came
out
of
the
hackathon
I.
E
Think
there
was
one
other
one,
but
I
was
I
was
super
impressed
I
think
everybody
was
with
I
want
to
participate
in
those.
Those
look
like
the
best
part
of
the
me
of
the
ietf
meeting.
So
maybe
I'll
try
to
do
that
more
next
time.
Thanks.
B
A
There's
a
link
I
can
throw
into
chat,
probably
when
I'm,
not
talking,
which
is
about
a
10
minute,
hackathon
readout,
but
the
the
the
basic
thing
that
we
did
was
Mike
Rickert
and
a
few
other
folks
at
Microsoft
were
working
on
a
an
open
source,
an
open
source
kind
of
skit
emulator,
as
they
called
it,
which
is
a
client
behaving
to
the
best
of
our
knowledge
against
the
draft
rest
API
and
a
server
that
just
takes
science
statements
and
sticks
them
in
a
ledger
gives
you
a
cozy
receipt
back
and
then
you
can
verify
that
on
on
the
other
end,
so
that
was
all
sort
of
pre-work
ahead
of
the
hackathon.
A
Then
at
the
hackathon
itself
we
showed
a
couple
of
interoperable
implementations
of
that.
So
Ori
and
transmute
have
a
an
encoding
and
decoding
tool.
That's
able
to
take
sign
statements,
cozy
sign
one
statements,
throw
them
in
make
a
receipt,
and
then
you
know
check
that.
A
All
of
that
all
that
works,
and
that
was
interoperable
with
the
open
source
sort
of
test
client
and
what
I
did
was
slightly
different
I
gave
the
drafts
back
and
a
link
to
the
go
cozy
library
on
GitHub
and
told
a
couple
of
my
engineering
team
to
give
it
a
go,
so
not
only
to
implement
the
the
simple
interoperable
receipts
format,
but
also
to
see
how
good
the
quality
of
the
spec
is.
A
Whether
people
could
actually
follow
it,
who
aren't
really
involved.
So,
although
they're
in
my
company,
these
two
particular
folks
have
never
touched
skit
or
attended
one
of
these
meetings
or
anything
like
that
and
happily
they
were
also
able
to
do
that.
So
one
really
important
thing
that
we
proved,
which
I
think
has
been
a
question
over
time,
was
that
the
minimal
cozy
receipt
format,
which
is
essentially
an
enumeration
and
a
Merkel
tree
proof.
A
A
packed
Merkel
tree
proof
that
that
actually
works
three
different,
independent
implementers
all
did
it
and
we
all
have
cryptographically
verifiable,
open
source
implementations
of
skit
receipts
in
that
format.
That's
that's
prescribed
in
the
current
draft
architecture
so
yeah.
We
actually
had
an
end-to-end
implementation
with
with
my
live
service
and
with
transmute
and
and
Microsoft,
also
taking
a
Json
structure,
calling
it
a
claim
signing
it,
submitting
it
to
a
service
over
the
standard
API
and
getting
back
a
fully
offline,
independently
verifiable
receipt
in
the
Cozy
format.
A
So
it
was
pretty
pretty
decent
really
and
it
didn't
didn't,
take
terribly
long,
which
is
which
is
great,
so
I'm
going
to
stop
there
because
there's
a
person
in
the
queue
that
doesn't
answer
Ray's
very
specific
question
about
verifying
The
Ledger.
But
we
can
come
to
that
in
a
second
Roy.
C
Thanks
John,
there
were
some
other
reviews
that
we
do
the
hackathon
through
the
the
architectures
document
and
smoking
questions
that
we
still
have
opinion
issues
that
we
have
to
go
through.
There
was
also
the
spin-off
working
to
the
Cozy
group
for
trying
to
get
Merkel
proof
receipt
approved.
C
The
other
comment
of
people
realize
is
due
to
reductions
in
some
of
the
stuff.
Microsoft
was
doing
the
team
that
was
working
on
the
open
source
emulator
was
let
go
so
I'm
trying
to
re-shuffle
that
and
adapt
with
all
the
other
tasks
that
were
also
impacted
across
the
company
and
picked
that
up
we're
a
little
bit
quiet
in
the
Microsoft
side,
but
we're
still
actively
working
through
all
the
other
issues
we
have.
At
this
point.
The
John
did
a
good
job
of
enumerating.
C
How
We
Do
Federation,
and
how
do
we
deal
with
some
of
the
the
bigger
aspects
of
it
and
I
still
think
we're
working
through
those
there's
open
questions
I
to
raise
question
I
always
thought
at
some
point.
We
may
need
an
out
for
the
various
implementations
to
do
a
very
deep
audit
of
ledgers
and
I'm
willing
to
be
proven
wrong.
On
that
conversation.
B
You've
been
working
on
is
that
public
has
that
been
sort
of
published,
despite
all
the
developments
in
Microsoft.
C
So
the
answer
that
they're
in
a
completely
different
group
than
I
am
and
then
people
around
the
company,
so
no
I
have
not
seen
what
they've
done.
I
have
to
go,
find
that
code
from
shiv
and
others
and
see
if
I
can
pull
it
into
another
group
or
take
ownership
of
the
repo.
So
I
can't
comment
on
this
point.
Okay,.
A
Yeah,
so
the
let
me
put
that
link
in
as
well
so
that
at
least
the
code
up
to
the
point
of
the
hackathon
plus
some
some
work-
that's
been
going
on
and
a
branch
is,
is
open
source
and
is
available.
I'm
an
admin,
a
number
of
folks
in
the
working
group
or
admins
on
that
that
repo
and
I
mean
frankly,
everybody's
everybody's
welcome.
Obviously,
so
let
me
stick
that
in
the
I'll:
stick
it
on
the
end
there
there
you
go.
A
A
There's
there's
no
interference
with
the
open
source
code,
but
we
weren't
quite
sure
whether
we
wanted
to
push
that
or
when
we
would
want
to
push
that
before
there's
a
second
alternative.
But
anyone
who
wants
to
see
it
working
or
whatever
I'm
happy
to
I'm
having
to
go
with
the
will
of
the
group
how
quickly
we
do
that.
A
So
to
the
question
very
interesting
question
about
how
deep
of
an
audit
we
need
to
do
with
with
ledgers,
I
think
that's
a
great
question,
because
the
more
we
prescribe
that
the
more
we
will
restrict
innovation
in
how
things
are
actually
protected.
So
you
know
transmute
and
archivists.
Both
use,
Merkle
trees,
I'm,
not
quite
sure
what
transmute
uses
I
just
use
the
ethereum
and
the
auditability
of
all
of
these
things
is
relatively
straightforward,
because
it
follows
the
auditability
of
hundreds
of
other
sort
of
blockchain
type
networks.
A
We
use
completely
standard
code,
we
use
Quorum,
we
use
consensus
tools
and
we
use
regular
Merkle
trees
and
regular
confidential
transaction
math
for
doing
the
the
key
distribution
of
federation.
So
it's
highly
auditable
and
verifiable,
given
just
a
few
routes
of
trust,
plus
whatever
you
know,
admin
keys
and
passwords
and
whatever
you
need
to
look
at,
but
that
will
always
be
there.
So
if
we
want
to
just
say
that
something
based
on
a
Merkle
tree
is,
is
what
we
mean,
then.
Actually
it's
relatively
straightforward.
A
All
that
kind
of
thing
with
my
chair
hat
off
I
would
say
that's
great
because
that
suits
me
in
my
commercial
capacity,
because
that's
the
product
I've
got
with
a
sort
of
Standards
development
hat
on
or
my
chair
hat
on,
I
would
suggest
it
might
stifle
Innovation
somewhat,
because
I
can
see
quite
a
lot
of
circumstances
where
that
complete
sort
of
network
based
or
fully
decentralized
or
consensus-based
thing
isn't
necessarily
the
best
choice
and
we
could
have
a
different
kind
of
append,
only
Ledger
enforced
by
different
maths
or
different
code,
but
obviously
that
would
make
it
much
harder
for
us
to
prescribe
other
than
thou
shalt
go
through
some
sort
of
audit
and
make
it
very
hard
for
us
to
prescribe
the
technical
points
of
that
audit.
A
E
No
I
I
think
I'm
kind
of
with
you
on
that.
I
would
not
want
to
get
too
balled
up
in
in
that,
because
I
do
agree
that
that
there
are
these,
these
already
existing
systems.
That
can
provide
that,
that
you
know
that
functionality
and-
and
so
then
then
either
because
I
was
kind
of
reflecting
on
the
thing
that
happened
with
the
the
time.
The
time
stamps,
where
yeah
they
can
give
you
a
time
stamp.
F
E
You
kind
of
don't
know
if
you
can
trust
it
and
then
to
figure
out.
If
you
can
trust
it,
maybe
a
lot
nearly
impossible,
and
so,
if
it
is
based
on
an
existing,
you
know
a
service
like
qldb
or
a
miracle
tree.
That
is,
you
know
well
defined.
E
Then
then,
maybe
we
can
get
out
of
really
exposing
too
much
there
and
just
say
it
has
to
be
done,
or
you
know
have
some
kind
of
principles
for
how
the
the
skit
Ledger
or
audit
log
you
know
whatever
the
thing
is,
will
be.
The
registry
will
be
audited
by
someone
else,
because
I
don't
think
most
people
that
using
this
want
anything
to
do
with
an
audit.
They
just
want
to
be
able
to
trust
that
the
audit
is
being
done
and
and
so
so
I'm
with
you.
E
I
won't
talk
anymore
right
now,
but
I
noticed
and
I
mentioned
here.
I
thought
Ori
had
something
that
was
pretty
cool
of
paper
that
was
written
on
on
that
I.
Don't
know
if
that
is
applicable,
maybe
or
he
wants
to
say
something
about.
B
B
A
B
Wonder
whether
this
whole
audit
topic
is
something
that
can
be
dealt
with,
let's
say
in
a
paragraph
in
the
in
the
architecture
document,
but
is
otherwise
beyond
the
scope
of
the
group,
because
in
general
for
IDF
groups,
I
would
I
would
argue,
it's
of
course
important
in
sort
of
for
the
deployment
and
so
on
and
so
on.
But
I
don't
think
we
need
to
worry
too
much
about
it.
C
Log
for
that
we
can
make
consistent,
that's
fine,
but
I
I
tend
to
agree
with
John.
You
know
the
issues
of
what
are
you
doing
15
years
from
now.
If
the
thing
has
been
put
on
tape
and
into
stone
in
Iron
Mountain,
those
things
are
not
going
to
be
always
available
online,
so
we
need
kind
of
this.
What
are
we
going
to
do?
Sort
of
conversations
and
I
I
agree
with
John
that
getting
too
deep
will
kind
of
staple
Innovation.
A
Yeah
by
way
of
just
making
sure
we
actually
get
our
our
outcomes
and
things.
Maybe
this
is
another
candidate
for
one
of
the
priority
work
items,
because
we
we
did
promise
some
months
ago
now
to
get
the
security
Target
done
and
a
good
way
of
dealing
with
this
might
be
to
add
operational
or
key
integrity
requirements
to
the
security
Target.
And
then
the
audit
question
simply
becomes
all
of
these.
Things
are
adhered
to,
so
yeah,
no,
no
single
human
shall
have
access
to
the
root
signing
key
of
a
timestamp
server.
A
E
To
be
important
to
do
it's
going
to
be
more
complex
than
that
more
having
just
one
person
or
like
saying
more
than
one
person.
Isn't
enough
I'll
tell
you
right
now,
but
but
I
think
have
having
a
way
to
to
say
okay
for
this,
maybe
we
can
profile
it
later.
I
don't
want
to
I
brought
this
up
only
because
I
thought
it
was
something
that
did
need
to
be
done.
E
I
don't
know
if
we
need
to
do
it
right
now,
there's
a
lot
of
things
that
seem
like
they
could
be
more
easily
dealt
with
in
this.
This
is
pesky
issue
and,
and
so
I'm
certainly
think
we
should
acknowledge
that
it
exists
and
then
work
on
it,
like
you
say,
with
a
paragraph
or
something
later.
Thank
you.
B
Okay,
to
search
it
back
to
the
meeting
after
the
discussion
we
had
just
earlier
about
the
hackathon
I
think
for
us
it
would
be
good
to
know
about
who
is
interested
to
do
a
little
bit
of
preparation.
Work
for
the
hackathon
like
I
know.
It's
there's
still
some
time
to
do
that
work,
but
I
think
it
would
be
worthwhile
to
have
a
separate
conversation
about
what
we
could
focus
on
the
hackathon.
Who
is
writing
what
code,
so
we
can
actually
show
something
afterwards
they
are.
You.
G
G
Yeah,
hello,
Hamas,
hello,
everyone,
yes,
oh
yeah
would
like
to
be
a
consumer
side
tester.
So
we'd
like
we'd,
be
interested
in
writing.
Whatever
software's
needed
to
query,
you
know
transparency
service.
So
that's
the
that's
the
part
we
have
the
most
interest
in
thanks.
B
Okay
and
Ray
already
mentioned
earlier
that
he
would
be
interested
in
I
assume
John.
You
I
can
definitely
put
your
name
down.
B
Cool,
what
about
the
others,
hang
can
I
see
Ori
and
Roy.
B
I
I'll,
let
you
think
about
it,
but
hopefully
hopefully
you
you
joined
that
development
as
well.
In.
B
Could?
Okay
and
you
you
will
be
most
interested
in
the
sort
of
like
the
lecture,
type
of
side
of
things
or
more
on
the
on
receipts
or
or
apis,
or
what.
C
I
had
to
figure
out
where
we're
short
and
I'll
try
and
get
other
people
to
fill
in,
but
I
think
the
ebi
stuff
and
the
rest
of
it
is
something
we
have
to
get
further
along.
B
Okay,
but
I
I
will
write
down
your
name,
so
that's
good
I
think
you
just
jumped
into
the
queue.
D
Yeah
because
too
many
view
buttons,
I
wasn't
you
think
here,
but
on
my
headphone
I
forgot
that
so
yeah
so
interesting
topics
to
work
on
is
how
do
you
feel
coming
over
and
over
this
again
we
have
to
consolidate-
and
this
isn't.
This
is
a
long
term
work
thing,
but
it
has
to
be
done.
The
the
policism
Force
for
an
issue
to
write
a
a
signed
statement
to
the
transparency
server,
so
it
becomes
a
transparent
statement.
That
thing
has
to
be
gate.
D
There's
a
Bill,
Gates
keeper
function
here
and
we're
calling
this
gatekeeper
function
and
that's
after
discussions.
That's
a
great
name,
a
registration
policy
and
I
think
that
really
ripples
through
a
lot
of
other
work,
because,
ideally
such
a
registration
policy
would
allow
for
a
marshalling
and
encoding
and
in
sibo
that
would
be
nice
so
that
that
kicked
off
other
things
that
we
are
trying
to
figure
out
right
now,
because
we
will
definitely
not
invent
a
totally
new
policy
language
that
doesn't
make
sense.
D
But
there
are
candidates
out
there
that
are
prominent,
which
everybody
can
agree
upon
and
they're
using
Json,
and
that
is
very
close
to
using
CDA
to
sibo
in
the
end
and
and
let's
find
out
that,
how
much
we
can
done
until
the
next
episode
meeting
on
that
front,
because
why
is
that
so
important?
D
Because
these
can
change
and
the
receipts?
Probably?
And
that's
a
that's
a
point
of
discussion.
I
think
we
have
to
consolidate
it
at
7.17,
is
that
the
receipt
will
will
have
to
present
some
indication
which
policy
was
in
place
when
the
science
thing
was
accepted,
because
if
for
a
minute
a
registration
policy
changed
and
was
accepting
some
nonsense
so
to
speak.
This
becomes
garbage
and
garbage
out
and
therefore
will
lose
the
property
of
judgments.
Obviously,
so
you
have
to
find
out
for
deep
audit
and
I.
D
Think
that's
one
of
the
things
you
want
to
deep
audit
at
some
time
has
how
what
was
the
threshold
for
policy
supplied
for
checking
them?
Was
it
in
scope?
D
Two
bears
in
the
weasel
is
in,
or
was
it
like
a
hard
atomistic
thing
that
was
was
making
it
basically
on
a
fundamental
level,
incapable
obviously,
then
and
I
think
that's
a
very
important
thing
for
the
one
of
the
teas
and
sketch
and
and
so
I
assume
that
all
this
discussion
we're
doing
right
now
on
on
the
howl,
encoding
and
and
and
and
not
really
but
weird
for
policy
language
will
will
end
up
in
a
representation
in
the
receipt.
But
that
is
a
long
road.
There's
a
lot
of
ifs
here.
D
We
will
try
to
check
as
many
boxes
as
possible
until
the
next
idea
of
meeting
to
to
have
some
better
understanding,
then
I
think
that's
an
important
item.
We
have
to
deal
with
on
a
daily
basis.
Basically,
under
that.
B
Yeah
I
I
added
some
nodes
to
the
meeting
minutes.
Please
check
what
I,
like
obviously
very
brief
captures
what
you
had
in
mind,
but
that's
already
pretty
good
and
I
hope
the
others
who
didn't
say
anything
hours
or
thinking
about
attending
the
hackathon
and
contributing
something
to
their
work.
I
assume
Ori
is
going
to
work
on
the
receipts,
but
I,
don't
think
he's
listening
right
now,
good,
okay,
John!
Is
there
something
else
to
add
to
that
hackathon
I
think
that's
pretty
good.
B
Already
I
will
send
out
an
email
to
the
list
to
see
whether
there's
someone
else
who
hasn't
had
a
chance
today
to
join
the
meeting
and
would
otherwise
start
to
plan
for
the
hackathon
itself
for
the
next
one
great.
A
So
I
think
just
just
two
short
things
so
yeah,
that's
enough!
I
do
want
to
Echo
the
point
that
that
Roy
sort
of
almost
made,
which
is
that
there
was
a
lot
of
other
works.
It
wasn't
just
the
code
ready.
There
was
a
lot
of
hacks
backing.
You
know
spec
hacking
and
that's
that's
important
too,
so
we
we
might
expect
people
to
show
up
at
the
hackathon
simply
to
do
dedicated,
editing
and
and
complicated
spec
work,
and
that's
that's
all
great.
A
The
other
thing
is
just
to
make
an
appeal
I
suppose
we
have
landed
by
default
on
sort
of
registration
policies
being
the
thing
we
prove
we,
we
did
sort
of
think
as
as
chairs
as
we
look
through.
All
of
the
activity.
Registration
policy
seems
to
be
the
thing
that
is
most
wanted
and
most
valuable
to
work
towards
at
117..
I
just
want
to
put
out
an
explicit
appeal
to
ask:
if
anybody
thinks
that
isn't
the
the
sort
of
area
we
should
be
targeting
for
117
or
if
there's
a
different
candidate.
A
B
Yeah,
okay,
that
was
the
hackathon
now
jumping
to
the
did
topic
and,
and
maybe
I
I
summarize
how
I
understood
sort
of
where
we
are
today.
So
we
had
an
email
discussion.
I
will
look
up
the
link,
it
was
a
good
thread.
Various
people
provided
feedback
and
my
impression
was
that
there
were
two
did.
B
Methods
and
I
will
also
post
a
link
into
the
chat
box,
namely
that
did
key
message
and
they
did
webmaster
and
both
of
those
methods
are
not
actually
finalized
yet
so
they
are
working
progress
specifications.
My
understanding
is
that
the
key
method
is
less
mature
than
the
web
method,
but
both
of
them
were
mentioned.
I
read
through
both
of
them
and
the
the
web
method
roughly
works
as
follows.
B
B
B
And
so
the
idea
is
then
and
then
there's
there
are
variations
with
paths
and
so
on
will
ignore
those.
But
the
idea
is
that
you
you
as
a
developer,
you
have
a
domain
name
and
you
store
your
edit
document
in
a
specific
place
on
that
domain.
And
if
you
send
someone
or
someone
has
access
to
your
did
web
URL,
they
can
basically
find
you
the
key
in
that
or
the
whole
did
document
in
the
corresponding
key
and
applied
to
the
skid
case.
B
That
would
mean
that
this
developer
then
has
obviously
simple
session,
somehow
of
the
private
key
and
stores
it
somewhere,
hopefully
secure
on
his
development
machine,
and
then
he
uses
that
to
First
gather
the
statements
and
then
to
sign
the
statements
using
that
private
key
and
then
send
that
sign
statement
to
the
append.
B
Only
a
lecture
which
then
looks
at
this
and
retrieves
the
the
did
document
verifies
also
the
the
signature
and
then
there's
all
sorts
of
other
processing
and
then,
finally,
if
everything
is
successful,
it
turns
the
receipt
that
we
talked
about
before
that's
kind
of
the
the
way
how
I
understood
it.
And
but
of
course
none
of
this
is
described
anywhere
and
so
I'm
wondering
whether
I
understood
it
correctly
and
what
Echo
specifically
was
asking
for
in
that
email.
B
Discussion
was
to
ideally
select
a
small
number
or
even
one
of
those
did
methods,
because
there
are
many
of
them
registered
in
to
describe
it
as
applied
to
skit
and
to
elaborate
on
the
security
properties
of
that
scheme
and
because.
B
Which
I
didn't
talk
about
the
Deep
key
method
is
very
different,
and
then
there
are
many
others
so
and
I
think
that's
definitely
something
we
need
to
do
and
if
that
would
also
be,
in
my
opinion,
a
good
Target
for
a
hackathon
activity
to
get
that
dip
handling
in
in
quotes
identity
management
cupboard,
because
that
was
also
a
significant
difference
to
the
six
store
project
which
used
open,
ID,
connect
and
and
ephemeral
public
private
keys,
as
you
heard,
I
think
it
was
in
January
when
we
had
that
presentation.
G
Yeah,
honest,
in
fact,
what
what
I'd
like
to
suggest
is
that
we
start
with
a
pretty
simple
use
case
for
the
hackathon
and
and
what
I'm
I'd
like
to
put
forward
a
proposal
that
we
to
demonstrate
how
skit
can
be
used
to
supply
consumers
with
software
trust
scores.
As
one
simple
example
of
how
it
could
be
used
and.
B
G
B
Could
any
any
other
thoughts
on
this
one
or
did
anyone
look
at
other
methods
which
went
mentioned
in
a
discussions
and
probably
they
are
more
favorable
for
use
with
kit
than
then
they
did
weapon?
They
did
key
method.
A
A
Technical
note
that
we
did
use
oidc
for
all
of
the
hackathon
targets
and
it
works
really
nicely
so
there's
a
there
is
a
question
over
the
kind
of
application.
Level
implementation
versus
the
core
route
standard
elements
of
persistent
data,
so
I
think
did
web
did
key,
are
perfectly
fine
to
be
proxied
through
and
use
oidc,
but
just
worth
bearing
in
mind
could.
B
You
elaborate
a
little
bit
on
that,
but
you
like,
of
course
in
the
the
web
case.
There
is
the
assumption
that
somehow
the
developer
is
able
to
load
digit
document
securely
onto
his
web
page.
It's
obviously
something
that
is
kind
of
out
of
scope,
or
where
did
you
is
that
the
place
where
you
used
automatic,
connect
or
or
somewhere
totally
different.
A
A
The
way,
the
way
the
emulator
Works,
which
is
quite
neat,
really,
is
that
the
client
is
a
single
client
that
absolutely
anybody
can
use
no
matter
what
service
is
they
are
interacting
with,
and
then
you
just
specify
as
a
configuration
which
service
you
want
any
particular
request
to
go
to
so
there's
only
one
piece
of
client
code
and
one
client
authentication
to
do,
and
then
that
gets
sent
through
to
a
separate
back
end
which
could
be
archivist.
It
could
be
an
emulator.
A
It
could
be,
you
know,
Carfax,
probably
for
for
dick
or
anybody
else.
So
IDC
is
just
a
really
nice
way
of
collecting
up
all
of
these
different
application.
Level
claims
to
reuse
an
unhealthful
word
and
Transit
those
through
multiple
authentication
contexts,
and
it
works
really
nicely
with
the
standard
web
Frameworks
and
request
tool,
belt
and
stuff
like
that.
So
for
the
rest
API
and
for
the
standard
client,
it
was
a
really
nice
way
of
getting
the
auth
data
through.
A
But
of
course,
auth
and
ID
are
not
exactly
the
same
thing,
so
the
identity,
primitive
itself
and
things
like
proof
of
possession
of
a
key
those
are
separate
to
creating
an
oidc
context
in
the
first
place.
So
I,
don't
I,
don't
see
any
problem
as
such.
It's
just
a
practical
thing
to
think
about
how
we
would
I
I,
guess
a
warning
not
to
pollute
what
is
identity
and
what
is
authorization
because
they're,
because
they're
different.
G
Yeah
I'm
I'm,
trying
to
get
back
in.
Thank
you
harness,
so
one
thing
I
I
would
like
to
see.
If
we
can
do,
it
is
set
up
a
test
bed
page
somewhere
on
you
know,
data
tracker
or
wherever
we
we
want
to
that,
has
all
the
details
about
which
services
are
available,
documentation
on
how
to
interface
with
those
services,
and
if
you
do
have
any
code
like
what
John
was
describing
like
a
a
client
code
that
calls
the
apis
having
that
available
through
that
one
testbed
type
page
I
think
would
be
very
beneficial.
Thank
you.
B
I
think
we
we
can
actually
put
links
to
implementations
to
the
sort
of
working
group
page
there's
a
separate
sort
of
with
each
specification.
There's
a
separate
sort
of
item
related
implementations,
I
think
it's
called
where
we
could
include
pointers
to
those
to
those
implementations,
so
that
may
actually
be
quite
useful.
B
G
B
Okay,
yeah
I
will
I
guess
John.
You
had
a
couple
of
links
in
your
presentation.
I
need
to
look
it
up
and
add
that
to
the,
for
example,
to
the
architect
architecture
specification
as
these
related
implementations,
I,
think
that
could
help
but
question
to
you.
John
did
you
document
the
use
of
automatic
connect
for
these
for
these
restful
apis
somewhere,
because
I
think
that's
something
that
is
missing
in
the
in
the
architecture
specification?
Maybe
maybe
maybe
it
could
be
described
right.
A
It
could
it
was
actually
Mike
Mike
Rickert
who,
who
put
it
in
so
I,
guess:
I
didn't
put
it
in
my
work
product.
It
is
part
of
the
readout.
So
if
we
take
the
hackathon
slides,
which
is
just
part
of
the
standard
deck
so-
and
you
know
everybody
here
has
access
to
the
116
materials
and
the
the
ignore
the
chair
materials.
A
That's
just
the
standard,
you
know
fire
escape
stuff,
but
the
actual
presentation
materials
includes
the
kind
of
the
end-to-end
flow
and
oidc
is
in
there,
and
it
is
documented,
very
briefly
in
in
one
of
Mike's.
A
Pull
request
is
probably
not
as
clear
as
it
might
be
so
yeah,
let's
take
a
look,
I
mean
it
would
maybe
dick
you
and
I
could
have
a
a
chat
offline
and
see
how
easy
it
is
for
you
to
pick
up
the
stuff
that
we've
done
already
and
then
anything.
That's
not
clear
that
clearly
becomes
a
candidate
for
being
better
documented
on
the
in
the
readme,
rather
than
just
in
PRS
yeah.
G
G
H
A
Work
yeah,
so
we've
got
that
brilliant,
brilliant,
so
we've
got
the
the
open
source
thing.
I
put
those
links
in
the
hedge
hedge
doc
notes
already
for
this
meeting,
so
yeah
we'll
work
on
the
all
the
open
source,
stuff,
the
skit,
Community
stuff
and
yeah
good
I,
I
I.
Don't.
B
Think
it
should
be
too
hard,
John
I
looked
at
this
slide,
you
didn't
include
include
links
into
the
slides,
but
so
like
I
think.
Maybe
we
need
to
also
on
the
description
that
Mike
has
been
working
on.
B
We
need
to
look
this
up.
I
think
this
would
be
good
material
for
a
next
draft
iteration
architecture.
B
Too
much
Ori
has
posted
into
the
chat.
We
talked
about
the
resolution
and
did
it
resolution
was.
This
was
something
I
didn't
I
didn't
look
at
so
so
this
may
be
yeah
thanks
for
sharing
Ori.
Do
you?
Are
you
available
to
Briefly
summarize.
H
H
Yeah,
so
many
folks
were
frustrated
with
what
the
did
working
group
chose
to
standardize
and
chose
not
to
standardize,
and
one
of
the
sort
of
contentious
points
was
did
resolution,
which
is
the
process
that
converts
a
dead
URL
into
a
representation
of
a
document
or
a
particular
key
within
a
did
document,
and
so
this
community
group
specification
here
describes
did
resolution
from
the
perspective
of
an
HTTP
web
server.
So
this
is
a
middleware
component
that
you
can
take
a
dependency
on.
H
If
you
need
to
resolve,
you
know
any
did
method
regardless
of
what
kind
of
method
it
is.
But
then
you
need
a
trusted
resolver
because
obviously
you're
returning
key
material
and
it's
important
that
you
trust
the
thing
that
you're
getting
public
Keys
from
so
that's
kind
of
like
the
basics
of
how
did
resolution
works,
you
take
a
data
URL
in
you
get
back
at
the
document
which
contains
keys
and
various
relationships
for
us.
H
The
relationships
we
would
care
about
are
the
authentication
relationship
and
the
assertion,
method,
relationship
and
then
inside
of
those
relationships
are
specific,
key
serializations,
usually
in
jwk
or
multi-base
format.
And
so,
if
you
want
to
resolve
a
particular
key
used
to
sign
a
Json
web
token
or
a
seaboor,
you
know
cozy
sign
one.
You
need
to
look
inside
at
the
did
document
in
the
particular
relationship.
You're
expecting
find
the
public
key
and
then
use
that
to
verify
the
signature.
B
Could
but
thanks
when
do
you
expect
the
the
specifications
that
did
methods
to
be
finalized
or
is
there
is
this
or
is
it
a
working
sort
of
a
living
document?.
H
It's
not
a
living
document.
The
working
group's
currently
not
active,
there's
a
chartering
process
for
the
next
Charter
version
of
the
working
group
that
chartering
process
is
being
held
up
because
of
w3c
process
and
politics,
and
most
of
the
folks
working
on
dids
also
work
on
verifiable
credentials,
and
so
that
is
that
working
group's
currently
active
and
so
a
lot
of
their
time
is
being
spent
on
deliverables
for
the
verifiable
credentials.
H
Working
group
currently
I
think
the
next
Charter
for
the
did
working
group
will
allow
either
the
concrete
specification
of
what
did
resolution
means,
or
and
or
concrete
specification
of
a
single
specific
did
method
like
a
standard
one.
It's
just
incredibly
politically
contentious.
That
second
part,
because
obviously
standardizing
particular
method
raises
the
Specter
of
you
know
particular
vendor
Technologies
or
blockchain,
or
you
know
these
other
things,
and
so
there's
a
lot
of
frustration
over
like
many
people,
don't
want
the
w3c
to
standardize
a
particular
did
method.
H
They
want
they'll,
be
3C
to
Define
resolution
for
all
bid
methods
and
other
people
want
it
to
just
Define
did
web,
for
example,
and
and
not
Define
resolution
for
all
did
methods.
So
that's
kind
of
what's
going
on
right
now,
I
think
the
expected
timeline
is
like
years
for
getting
a
did
method
to
the
through
the
standardization
process
at
w3c.
H
H
But
it's
still,
you
know
that's
a
lot
of
work
that
has
to
be
done.
Yeah.
B
Yeah,
just
only
bore
it
a
little
bit
because
because
there's
obviously
a
dependency
and
having
at
least
one
method
described
very
clearly
would
provide
a
benefit
to
developers,
and
ideally
it
would
be
just
finalized
already
and
and
would
not
have
to
worry
about
it,
because
they
did
a
key
method
which
I
didn't
talk
about
that
is
so
different
to
the
web
method,
obviously
because
otherwise,
why
would
you
have
to?
B
But
it
it
leaves
out
a
lot
of
the
sort
of
challenging
aspects
like
it.
Just
has
the
if
I
understand
it
correctly,
the
URL
has
just
a
key
India,
so
that
and
the
public
key
in
a
in
a
specific
encoding.
B
B
Okay,
yeah
thanks
thanks
URI,
for
it
did
jwk,
which
I
didn't
look
at
so
it
wasn't
that
wasn't
raised
any
discussions,
but
I
I
definitely
think
that
eckers
right
in
the
sense
that
we
need
to
at
least
have
one
method
to
clearly
explained
and
on
and
not
the
method
to
explain,
but
how
it
relates
and
is
used
in
skipped,
so
that
would
that
would
be
important.
B
E
I
think
that
it
sounds
similar
to
the
it
seems
similar
to
the
initiatives
that
were
very
interesting
at
the
last
ietf
meeting.
Regarding
how
to
to
make
you
know
your
public
Keys
available.
E
I,
don't
know
if
that
was
a
good
match.
First
skit,
the
dead,
stuff
and
I'm
gonna
have
to
read
this
some
more
and
study
it
I'm
trying
to
get
some
time
to
to
Really
spend,
but
the
it
seems
like
it's:
okay
with
skit
for
us
to
have
a
little
bit
less
or
more
constrained
access
to
the
keys,
but
maybe
not.
E
It
seems
like
that
that
whole
thing
about
whether
you
you
were
talking
about
putting
the
the
public
key
in
a
URL
I
hadn't,
seen
that
one,
but
the
the
concept
of
how
do
you?
How
do
you
provide
the
public
Keys
Etc
was
was
the
subject
of
all
those
discussions
that
were
pretty
interesting?
E
Okay,
so
so
I
anyway?
It's
it
it's
in
the
same
realm
of
of
I,
think
but
I
I
don't
want
to
belabor.
It
I
think
that
I'm
just
going
to
I
see
arya's
answer
just
a
little
bit.
E
Thank
you
and
I
will
I
will
study
it
some
more,
but
we
do
need.
We
do
need
that.
You
know
we
need
a
way
to
to
provide
public
keys
in
my
situation,
I'm
also
looking
at
how
do
I
provide
the
public
keys
of
devices
which
are
which
have
a
private
key?
That's
you
know
nested
inside
and
that
no
one
can
get
to
and
I
need
to
have
those
all
those
public
Keys
posted.
E
B
Yeah
I
I,
unfortunately,
cannot
tell
you
and
how
it
relates
to
key
trans,
because
I've
I
wasn't
at
that
meeting.
So
we'll
have
to
reach
out
to
the
GS
to
see
what
the
next
steps
they
are.
B
Hank.
You
raised
your
hand.
D
Yeah
I
was
coming
back
to
the
horrible
words
that
some
sdos
slower
than
the
ITF
sorry,
and
so
so
no
yeah
we
can
do
our
own
did
Flavor.
D
So
what
I
would
so?
You
know
my
naive
and
and
hopeful
nature
and
they
love
in
India.
So
much,
and
so
some
of
my
my
proposal
would
be
that
we
mimic
the
resolution
of
did
Uris
for
today,
as
as
that
described
by
w3c,
we
implement
the
naive
version
of
each
Sea
World
phase.
D
What
works
make
our
own
addendums
to
them
find
out
when
w3z
moves
again
if
they
move
into
a
different
directive,
do
it
here
and
create
another
flavor,
because
we
can't
install
on
on
so
we're
not
doing
the
ideas,
because
the
idea
is
so
cool.
We
are
doing
deities
because
we
need
flexibility
and
identity
document
agility
and
we
can't
be
stuck
into
pkix,
because
that
won't
work
for
long
and
so
so.
D
I
think
that
the
ID
route
is
an
escape
mechanism
to
allow
to
move
from
various
continues
to
others,
create
conduits
between
them
and
and
allow
for
different
identity
document
formats
to
and
to
operate,
and
and
if
that
can't
be
achieved
in
the
near-term
goal
by
a
w3c,
stable
dead
web.
D
Well,
then
we
have
to
act,
but
but
we
have
to
also
Implement
so
I
think
the
hackathon
and
the
implementations
and
the
the
text
we
write
will
show
what's
working
and
what's
not
working
if
we
are
diverging
from
essential
decisions
from
the
dwcc
at
some
point
we
have
to
Splinter
off.
I
would
have
been
assuming.
D
So
that's
my
point
of
view,
so
we
we
shouldn't
shouldn't,
be
deterred
by
the
decipheness
and
the
particularness
of
the
Ws.
We
see
we
should
take
this
as
an
opportunity
to
test
it
thoroughly
and
have
our
own
opinion.
D
G
Thank
you
harness
so
I'm
not
familiar
with
jid.
So
maybe
my
question
is
really
sort
of
irrelevant,
but
here
it
is.
We
we
use
standard,
pki
type
Technologies
in
libraries
to
do
things
like
certificate.
You
know
verification
and
other
certificate
processing.
Will
we
will
we
be
able
to
use
the
existing
certificate
processing
tools
that
we
use
today
as
part
of
this,
or
did
something
completely
different.
H
Yeah
so
I
mean,
if
you
have
a
key,
that
is
a
certificate
and
you're
dereferencing
it
from
a
did
URL,
then
you
can
think
of
certificates
as
kind
of
fitting
inside
of
deads,
but
I
I
think
from
an
I
identity
perspective
like
they
in
some
way
solve
the
same
problems
as
as
honest
mentioned.
So
you
know,
Deads
were
designed
to
hopefully
be
backwards,
compatible
with
certificates.
H
Although
there
was
people
who
tried
really
hard
to
make
that
not
possible,
so
they
can
be
used
together,
but
I
think
if
you're
entering
a
world
where
you're
specifying
both
interfaces,
that's
gonna
eventually
become
sort
of
problematic
for
implementers,
because
they're
going
to
be
carrying
that,
if
statement
everywhere
around
in
their
code.
G
B
Well,
we
we
can,
of
course,
and
that's
also
I,
think
what
Ecker
asks
us
to
write
about
this
like
to
have
that
written
down
and
analyzed
and
to
see
what
the
results
are.
The
hackathon
would
give
us
the
the
extra
bonus
of
seeing
how
the
experience
looks
like
after
doing
that.
So
so
it
sounds
like
a
very
useful,
a
useful
exercise
for
us.
G
D
Yeah,
just
just
quickly
adding
to
Dick's
proposal
that
this
is.
This
is
a
the
fallback
use
case.
So
if
you
can't
do
the
the
the
connection
between
the
all
Continuum
of
pkx
and
new
consumer
of
the
flexibility
of
this
resolution,
well,
what's
the
point
right
so
so
I
think
yeah.
That
should
be
a
use
case.
We,
that
is
a
checkbox
for
the
hackathon.
G
G
B
Already
a
question
for
you
in
the
in
the
dead
case,
is
there
a
way
to
sort
of
instead
of
using
a
key
structure,
cozy
key
structure
in
white
not
the
courtyard
a
Json
web
key
structure
with
the
let's
say
for
elliptic
curve
cryptography,
X
Y
coordinates
instead
use
use
an
X5
for
nine
certificate
like
let's
say,
subject:
public
keying
for
something
like
that.
H
Yeah,
so
the
the
did
spec
describes
these
things
as
verification
material,
and
it
supports
basically
two
formats
that
are
acknowledged
in
a
specification
and
one
is
public
key
multi-base
which
uses
multi-base
encoding,
which
is
not
standard
but
popular
in
the
blockchain
community,
and
the
other
format
is
public
key
jwk
which
supports
the
x5u
and
x5c
parameters
that
are
used
for
working
with
certificates.
H
But
you
could
also
do
you
know
public
key,
pem
or
certificate.
You
can
invent
your
own.
You
know
object,
that's
going
to
be
included
in
the
verification
method,
that's
going
to
be
used
for
verification,
and
then
you
can
include
that
object
in
the
did
document,
but
obviously
not
all
did
methods
will
support
your
new
object.
Representation
for
verification
and
I
mean
that
might
not
be
a
huge
issue
if
you're
also
making
a
did
method
at
the
same
time.
H
But
if
you're
trying
to
make
this
work
with
every
did
method
out
there,
which
I
don't
think
anybody
should
try
and
ever
do
then
you're
better
off
sticking
to
jwk.
In
my
opinion,.
B
And
with
that
thanks
thanks
would
they
actually
be
a
sort
of
a
cozy
based
variant
of
this
as
well,
because
for
in
other
places
we
talked
about
like
using
using
a
cozy
cbos,
slash,
cozy,
face
structure.
E
H
That
I
would
not
encourage
anyone
to
use
cozy-based
structures
for
key
representations.
Currently
it's
very
hard
to
get
like
Library
support
that
understands
cozy
keys
and
there's
tremendous
amounts
of
contention
over
cozy
key
formats
on
the
Cozy
working
group
list.
I
think
jwk
is
a
much
better
portable
key
format
for
this
particular
layer.
B
But
it
doesn't
necessarily
need
to
be,
but
just
a
question,
because
if
we,
if
you
sent
the
that
web
URL,
then
obviously
that's
just
a
domain
name
plus
a
bath
element
and
then
all
the
other
stuff
would
happen
in
the
back
end.
And
then
you
would
be.
You
would
be
fine
using
json-based
things
in
the
in
the
back
end
anyway,
right.
B
B
I
think
I
see
that
we
already
exceeded
our
time
so
I
think
in
in
terms
of
the
debt
conversation.
I
think
what
would
be
good
is
to
get
a
few
interested
parties
together
and
write
something
up
so
that
we,
maybe
maybe
a
patreon
so
which
we
could
then
stick
into
the
architecture
document,
providing
readers
a
little
bit
more
background
into
how
we
plan
to
use
these
different
Technologies
in
combinations
is,
is?
B
Would
anyone
be
interested
in
that
sort
of
call
it
that
a
sign
team
or
whatever
you
like,
but
just
a
few
people
who
knowledgeable
in
that
area
and
interested
to
write
something
up
so
that
we
can
push
the
ball
forward?.
B
F
Hi
just
a
clarification
question,
so
then
you
mentioned
an
architecture
document.
So
would
this
text
go
into
an
already
existing
architecture
document,
or
are
you
asking
about
interest
or
volunteers
for
writing?
A
new
architecture
document
that
would
mostly
cover
did
methods.
B
Thanks
for
the
question,
yeah
I
was
thinking
more
about
the
existing
architecture
document
because
it
like
content-wise
I,
believe
it
it
fits
in
there
and
also
I,
don't
I
hope
it's
not
such
a
long
text
that
it
actually
justifies
its
own
undocumented
and
I
I
I
agree
with
Orion
tanks
previously
that
I
at
this
point
in
time,
I
I,
don't
think
we
have
anywhere
in
our
Charter
an
attempt
to
rewrite
well
produce
new,
did
method,
specifications
or
rewrite
an
existing
one
and
making
an
IDF
specification.
B
So
in
that
sense,
I
think
it's
mostly
about
clarifying
on
how
we
use
an
existing
technology.
In
our
context,
does.
F
F
That
definitely
answers
my
question
and
I
I
think
it
does
make
sense
if,
if
that's
good
without
thank
you.
B
Would
you
be
willing
to
contribute
to
that
work.
F
Without
making
big
commitments
right
now,
I
will
be
inclined
to
say
yes,
but
that
would
this
would
be
something
that
I
would
need
to.
You
know
take
back
to
the
team
and
discuss
a
bit
more
good.
B
Perfect
yeah,
please
let
John
and
myself
know
whether
you
have
some
spare
cyclists,
obviously
always
appreciate
it
right.
B
Yeah
and
and
of
course,
to
everyone
else,
you
think
about
it
and
because
I
would
like
to
move
this
topic
forward.
So
we
can
next
week
we'll
talk
about
the
registration
policy
unless
there's
some
other
suggestions
and
and
then
and
I
would
send
the
mail
about
the
hackathon
topic
as
well.
A
B
Yeah,
thanks
to
all
and
see
you
hear
you
next
week
great
thank
you.
Bye.