►
From YouTube: Digital Identity WG (January 6, 2021)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
just
one
thing:
we
clicked
the
recording
button,
so
this
meeting
is
now
being
recorded
and
will
be
uploaded
if
you
want
to.
You
want
to
watch
it
later,
david.
A
A
Well,
I'll
post
the
link
to
the
meeting
notes-
and
you
can
put
your
name
in
there
too,
when
you
get
a
second
for
attendance,
cool,
okay,
go
ahead,
michael!
Let.
C
C
Let
me
try
again
my
screen
and
screen
two.
Are
you
seeing
the
the
panel
of
everyone
on
the
screen
right
now.
A
C
Do
so
yeah,
so
thank
you
for
the
invitation
to
speak
today.
A
little
bit
of
background,
I'm
the
founder
of
a
company
called
glue.
Glu
is
our
domain.
C
C
And
so
this
this
this
project
has
a
number
of
components,
including
the
what
we
call
the
auth
server.
This
is
an
open
id
connect
provider.
So
it's
basically
like
a
self-hosted
google
identity.
C
We
have
a
number
of
other
components,
including
fido,
which
is
a
new
type
of
authentication
if
you've
ever
seen,
ub
keys,
that's
a
type
of
fido
device,
but
fido
includes
a
number
of
biometric
and
mobile
authentication
technologies.
So
this
is
all
an
alternative
to
passwords,
basically
and
so
anyway.
So
the
the
idea
with
johnson
is
that
you
know
a
lot
of
companies.
These
days
are
moving
to
self-hosted
or
I'm
sorry
to
to
cloud-hosted
identity
platforms
like
octa
and
auth0,
and
google
identity
and
microsoft.
C
Azure
id
and
those
things
are
great,
but
there's
still
a
subset
of
companies
out
there
that
see
this
component
as
something
that
they
need
to
build
into
their
product
or
for
some
reason
they
have
economies
of
scale
or
they
have
some
other
reason
for
security
or
privacy
where
hosting
identity
on
a
third
party
like
octa,
doesn't
work
for
them
and
they
still
need
software
to
do
this,
and-
and
so
that's-
that's-
sort
of
the
market
that
we're
in
so
companies
who
are
either
productizing
or
self-hosting
a
large
identity
provider.
C
They
want
to
build
their
own
google,
let's
say,
and
so
I
wrote
a
book
in
2018
or
so
that
I
published
with
apparas
called
securing
the
perimeter.
This
is
about
how
to
build
identity
and
access
management
infrastructure
using
open
source
software,
and
I
also
host
a
podcast
on
open
source
business
models.
C
So
if
you,
if
you're
crazy
enough
to
want
to
start
an
open
source
software
company,
which
I
highly
advise
you
not
to
do,
but
if
you're
crazy
enough
to
want
to
do
something
like
that,
I
would
say
definitely
listen
to
some
of
these
podcasts
there's
a
lot
of
great
information
from
founders
and-
and
so
this
is
one
of
my
side
projects,
but
but
we've
published
about
55
episodes
and
anyway,
but
I'm
getting
back
to
the
identity
stuff.
You
know
so.
C
I've
been,
I
started
glue
in
2009,
but
before
I
started
glue,
I'd
been
working
in
the
identity
space
for
probably
more
than
10
years,
and
I
think
I
started
a
company
called
id
vault
in
1998,
and
so
we've
been
looking
at.
You
know
this
type
of
problem
that
you're
looking
at
for
a
long
time,
and
I
have
some
thoughts
about
you
know
how
to
think
about
this
problem.
But
I
do
think
that
this
is.
B
C
Know
it's
it's
a
it's
a
very
it's!
I
understand
the
goal
here,
but
in
reading
the
goals
and
the
non-goals
in
a
lot
of
ways,
they
they
seem
to
be
contradictory.
C
So
so
these
are
really
tough.
This
is
a
really
tough
mandate
to
take
on
and
you
know
so.
What
I
thought
I'd
talk
about
today
is
in
in
chapter
10
of
my
book,
so
my
book,
actually
it's
pretty
geeky.
So
I
talk
about
ldap
and
saml
and
oauth
and
openid
and
two-factor
authentication
and
blah
blah
blah
blah.
C
But
in
the
last
chapter
chapter
10
is
about
what
I
call
multi-party
federation,
and
I
think
that
chapter
has
some
really
applicable
ideas
that
might
help
you
think
about
the
problem
that
you're
that
you're
trying
to
solve.
So
I
was
mostly
going
to
focus
on
on
some
of
these
ideas,
and
so
multi-party
federation
is
a
situation
where
you
have
a
number
of
autonomous
organizations
who
want
to
collaborate
in
order
to
improve
to
trust.
C
So
you
know
everyone's
familiar
with
sort
of
a
centralized
trust
model.
Like
let's
say
you
know,
google
right,
so
you
sign
up
for
an
account
at
google.
They
do
some
type
of
very
weak
identity
proofing.
You
get
an
account
and
then,
if
I
share
a
document
with
you,
you
know
you
have
a
gmail
account.
I
have
a
gmail
account.
C
You
know
I
can
specify
and
share
a
document
and
it
works
great,
but
we're
using
you
know
some
type
of
central
authority,
whether
that's
a
you
know,
e-commerce,
like
consumer
idp
or
whether
that's
a
government
or
something
we've
centralized
sort
of
trust
management.
C
In
that
you
know
single
silo,
but
complications
arise
when
we
have
multiple
autonomous
sources
of
identity
and
so
multi-party
federations
attempt
to
to
define
what
I
call
the
tools
and
the
rules
around
trust,
and
you
need
both
of
both
both
tools
and
rules
in
order
to
establish
trust
before
I
go
on
and
on
about
this,
I'm
just
curious.
Is
this
a
topic
where
which
you've
sort
of
been
looking
at?
Has
anyone
mentioned
of
you
know,
federations
or
before
I
preach
the
converted?
B
C
Okay,
I'll
keep
going,
and
just
if
I'm,
if
I'm
just
saying
a
lot
of
the
same
stuff
that
you've
already
talked
about
10
million
times.
Just
let
me
know
and
I'll
stop
yeah.
A
C
So,
let's,
let's
just
talk
about
sort
of
the
different
types
of
federations,
so
everyone's
familiar
with
a
certificate,
a
certification
authority
or
ca
or
tlds
top
level
domains.
So
here
we
have
a
root
trusted
authority
at
the
root
who
can
delegate
some
of
their
ability
and-
and
we
get
something
like
dns
right
so
dns
doesn't
the
vetting
process
for
a
domain?
Obviously,
is
not
that
great,
so
we,
I
always
say
like
the
internet,
was
great
at
connecting
us.
C
So
actually,
let's
look
at
the
internet
itself
as
a
federation.
The
internet
itself
has
a
lot
of
autonomous
parties
connected
to
it,
but
we
basically
only
agree
on
like
one
thing,
which
is
the
tcp
part.
We
agree
everyone's
going
to
have
their
own
ip
address
and
we're
going
to
have
these
routing
rules,
so
we
have
the
ability
to
connect
and
in
order
to
connect,
we
did
actually
have
to
agree
to
some
rules.
We
had
to
agree
to
ip,
not
really
even
tcp.
We
really
just
needed
to
agree
on
ip
and
and
so
we
get.
C
Basically,
the
internet
is
probably
the
world's
biggest
federation,
but
it
has
very
little
trust
in
it.
Basically,
we
can
only
trust
that
no
two
addresses
have
the
same
ip
address
and
that's
about
it.
So
dns
maybe
goes
a
little
bit
further
and
says:
okay,
we're
going
to
build
a
little
bit
of
infrastructure.
C
On
top
of
this,
if
you
want
to
use
a
name
you're
going
to
have
to
register
that
name
and
there's
some
type
of
hierarchical
federation
here
which
says
that
we're
going
to
set
up
we're
all
going
to
agree
to
rules
on
how
these
names
are
going
to
be,
you
know,
managed
and
and
how
who's
going
to
manage
tlds
and
we
get
sort
of
this
hierarchical
federation
note.
Each
domain
registry
might
have
different
rules,
so
the
vetting
process
for
getting
let's
say
a
domain
name
in
that
dot.
C
C
A
very
good
example
of
this
would
be
in
the
education
sector.
There's
a
federation
called
in
common
in
higher
education
and
in
common
has
about
500
universities,
500
websites
in
it
it's
a
saml
federation,
so
the
universities
have
students
who
want
to
authenticate
to
websites
and
the
websites
there's
both
business
and
technical
advantages
here.
C
So
if
we
look
at
incommon.org
and
we
look
at
the
federation
and
organizations
you'll
see
you
know
they
used
to
just
list
these-
I
think
there's
too
many
now,
but
there's
a
lot
of
universities
here
right
and
each
of
these
universities
has
their
own
identity
process
right.
So
how
you,
how
they,
how
you
enroll
as
a
student
or
faculty
member
each
university,
is
its
own
little
fifedem
and
they
have
their
own
processes
for
onboarding
students
and
faculty.
C
So
each
university
is
basically
an
independent
autonomous
domain
responsible
for
for
their
own
identities
and
there's
both
business
and
technical
advantages
to
the
federation.
So,
on
the
legal
side,
the
I
the
universities
are
regulated
by
by
the
government
for
privacy.
So
if,
if
you're
in
for
me,
if
you're
going
to
a
university
and
that
university
is
breached,
the
university
is
required
to
notify
you,
and
so
when
they
do
business
with
a
website.
C
They
need
to
know
that
if
that
website
is
breached,
that
they
tell
the
university
about
it,
and
so
the
federation
is
handy
because
the
university
could
make
let's
say
a
universities
using
50
websites
instead
of
needing
50,
one-off
agreements
that
say
make
sure
you
notify
us.
They
just
tell
all
the
websites
join
the
incoming
federation
in
that
incoming
federation.
C
There's
one
standard
agreement.
When
you
join
the
federation
there's.
Basically
they
don't
have
the
link
to
the
agreement
and
up
anymore,
but
there
is
basically
one
legal
agreement
that
you
sign
called
the
participant
agreement
and
that
in
that
participant
agreement
the
website
says,
if
there's
a
breach,
I'll
notify
the
idp.
C
C
So
there's
legal
efficiency
but
there's
also
technical
efficiency,
because
the
in
addition
to
the
standard
legal
agreement,
the
each
sp
and
idp
publishes
its
public
keys
and
saml
endpoints
to
the
federation.
C
This
information
is
vetted
and
then
published
by
the
federation,
and
so
this
is
really
handy
because
the
idp
doesn't
have
to
go
to
the
website
and
say,
send
me
your
certificate.
They
can
get
that
from
the
federation
in
one
place
and
they
can
know
in
the
sp
perspective.
It's
great,
because
if
I
update
my
private
key
or
my
public
heli,
then
I
can
update
my
public
key
at
the
federation
and
not
have
to
notify
50
different
web.
C
You
know
universities,
so
so
the
federation
has
been
really
a
good
way
to
manage
trust
or
to
scale
trust
between
universities
and
websites
and
there's
actually
the
biggest
federations
in
the
government
space.
The
department
of
justice
has
a
big
federation,
and
it
also
the
federation
also
defines
standards
like
if
every.
If
every
website
uses
a
different
attribute
name
for
first
name
and
last
name,
it's
going
to
drive
up
cost.
So
the
federation
can
publish
some
common
standards
like
we're
going
to
use.
C
C
We're
going
to
use
the
this
schema,
we're
going
to
disclose
our
identity
process,
we're
not
going
to
say
you
have
to
use
this
at
any
particular
identity
process,
but
we're
going
to
say
you
have
to
disclose
what
identity
process
you
use
in
order
to
so
we
know
we
can
make
a
decision
about
how
much
we
can
trust
an
identity
coming
from
your
idp,
so
the
federation
is
really
good,
for
it
provides
both
tools
and
rules,
so
the
rules
are
the
the
legal
part
and
the
and
the
standards
and
the
tools
are
things
like
the
certificate,
publication
service
and
and
the
vetting
process
website
and
stuff
like
that,
so
another
type
of
federation.
C
So
this
is
this
is
more
of
a
centralized
federation.
It's
a
proxy
federation.
This
is
probably
something
that
you
you
know
based
on
your
requirements
you
wouldn't
have,
but
in
the
banking
sector
in
canada,
for
example,
all
the
banks
are
idps
and
if
you're
a
website
that
wants
to
consume
an
identity-
and
you
want
a
bank
verified
identity.
C
There's
a
company
called
secure
key
that
runs
a
proxy
and
they
connect
all
the
banks
and
they
can
connect
your
website,
and
this
is
sort
of
great,
because
actually
this
this
entity
sits
in
the
middle,
the
federation
operator
sits
in
the
middle.
It
makes
it
really
easier
for
the
sp
to
get
connected.
It's
technically
efficient,
but
it's
from
a
privacy
perspective.
It
requires
a
lot
of
trust
of
the
central
provider
and
also
the
central
providers
and
the
critical
path
for
authentication,
and
so
it's
hard
to
scale
this
type
of
centralized
federation.
C
But
if
you
can
do
it,
it's
really
nice,
especially
for
for
both
sides.
It's
great
but
there's
also
privacy,
issues
around
what
data
gets
stored
about
the
person
and
and
what
data
passes
through
and
is
that
data
in
the
clear?
So
it
raises
privacy
issues,
because
this
federation
operator
in
the
middle
can
really
see
a
lot
of
information
and
there's
a
lot
of
privacy
issues
that
get
raised
there.
C
Then
we
have
interfederation
trust,
so
we
might
have
the
us
higher
education.
We
might
have
european
higher
education
and
you
can
get
inter-federation
trust
agreements
where
maybe
you
have
a
debian
community
and
you
have
a
suse
community
and-
and
you
say,
okay
well,
if
you're
a
susa
committer,
I
want
to
trust
you
in
the
debian
federation.
We
might
have
different
rules,
but
maybe
the
federations
will
make
some
agreement
about
how
to
how
to
sort
of
normalize
the
trust,
the
differences
in
the
trust
or
make
an
agreement.
C
So
so
this
is
another
topic
that
we
see
this
is
you
can
have
multiple
federations
and
those?
And
how
do
you
in
in
the
education
space,
there
was
a
deal
between
income
and
educating
where,
if
you're
an
american
researcher,
you
can
get
to
european
websites
now
because
there's
an
inter-federation
trust,
because
those
federations
have
have
an
inter-federation
agreement.
C
So,
there's
more
work,
that's
being
done
on,
what's
called
trust
marks,
so
this
is
work
that
came
out
of
gtri
the
georgia
tech
research
institute.
Basically,
this
this
came
out
of
basically
the
there's
law
enforcement
federations,
so,
for
example,
if
you're
in
the
fbi
or
the
texas
department
of
public
safety,
you
might
want
to
access
certain
databases,
and
so
they
have
to
know
you
know
if
you're
an
fbi
identity
accessing
this
database.
C
How
much
can
we
trust,
but
it
turns
out
in
the
law
enforcement
area,
there's
thousands
of
law
enforcement
agencies
in
the
u.s
there's
sheriff's
departments,
there's
park
rangers,
there's
so
many
and
what
they
found
is
that
a
top-down
approach
to
trust
didn't
work.
So
when
they
created
this
first
federation,
they
found
that
the
large
organizations
could
manage
to
participate.
So
when
they
launched
this
database
service,
for
example,
the
fpi
did
it
no
problem,
they
have
economies
of
scale.
C
Large
states
like
texas
joined
it,
but
most
for
the
most
part.
I
think
they
got
about
30
organizations
or
40
organizations
to
join
it,
but
for
most
organizations
the
requirements
that
they
put
on
joining
the
federation
were
too
high,
and
so
they
moved
to
another
approach,
called
trustmarks
where
they
said,
instead
of
you
having
to
sign
this
agreement
and
agree
to
align
with
certain
like
requirements
like,
how
do
you
identity
proof,
people?
And
how
do
you
secure
data?
You
know
they
had
all
these
security
requirements.
C
What
we
want
you
to
do
is
we
want
you
to
assert
trust
marks
and
they
made
a
trust
mark
which
is
like
a
little
piece
of
xml
that
discloses
a
security
policy
and
they
did
like
a
mapping
to
a
number
of
major
security
standards
and
they
said
just
tell
us
what
you're
doing
for
security,
and
then
we
can
do
have
sort
of
an
automated
trust
sort
of
like
we
said
instead
of
us
saying
you
know,
this
is
what
you
need
to
access
our
system.
C
We'll
say
tell
us
what
you
do,
what
are
your
identity,
management
and
security
policies
and
then
we'll
make
a
decision
based
upon
what
you're
doing
if
we
can
allow
this
transaction
based
on
a
risk
analysis,
there's
also
a
json
version
of
these
trust
marks
too.
So
it's
a
way
for
an
organization
to
sort
of
disclose
in
a
standard
format.
C
You
know
if
you
type
in
gtri
trust
marks.
I
believe
that'll
that
that
turns
up
this.
This
program,
the
the
this
was
funded
under
nstic
the
national
strategies
for
trusted
identities
in
cyberspace.
C
This
was
an
obama,
a
really
great
obama
program-
that
who
knows
maybe
it'll
come
back
now,
but
the
obama
administration
invested
basically
money
to
make
the
internet
a
safer
place,
and
this
this
project
from
gtri
was
funded
as
part
of
that
and
they've
really
done
a
nice
job
chapter
10
of
my
book
is
also
I
I
I
give
a
better
overview
than
I
just
gave
about
trust
marks,
but
yeah.
So.
A
C
Our
are
json,
so
there's
you
could
read
more
about
it,
but
basically
there's
like
a
thousand
trust
marks,
so
they're
very
granular.
So
like
do
you
use
strong
passwords?
Do
you?
How
often
do
you
change
passwords?
Are
you
using
to
you
know,
I'm
just
add
living
here,
but
there's
sort
of
a
trust
mark
for
like
everything,
every
security
policy
and
then
you
sort
of
say
these
are
the
security
policies
that
I
use
and
then
but
yeah.
C
It
was
originally
xml,
but
there's
a
json
there's
also
now
a
json
mapping
of
this
xml,
because
it
was
a
map
mapping
to
saml
stuff.
A
C
But
anyway,
the
the
the
getting
back
to
your
requirements
and-
and
so
let's,
let's
circle
back
to
what
you're
trying
to
do
and
figure
out
how
this
helps
you
so
so
trust
is
basically
derived
you
know.
C
Maybe
a
good
place
place
to
start
is
the
self-sovereign
identity.
So
this
is
the
idea
that
I
should
be
in
control
of
my
information,
and
so
it's
an
interesting
starting
point,
because
I
have
this
conversation
with
people
about
what
information
can
I
assert
about
myself?
That's
actually
useful
and
it
turns
out
there's
not
a
whole
lot
of
information
that
I
think
that's
useful
from
a
security
perspective.
C
I
can
assert
maybe
what
my
email
address
is,
but
there's
there
could
be
some
doubt
about
that.
I
probably
would
want
to
know
from
the
email
provider
itself
that
actually
you're
like.
If
I
want
to
assert
that
my
gmail
is
nynymike
gmail.com,
you
probably
can't
believe
me.
You
probably
have
to
go
to
google.
In
fact,
the
whole
purpose
of
openid
connect
was
to
enable
websites
to
verify
the
email
address.
C
Third
parties
to
verify
the
email
address,
the
gmail
address
of
a
person-
that's
really
important
for
e-commerce,
obviously
so
yeah,
I
can't
even
assert
my
email
address,
so
there's
very
little,
so
most
valuable
information
is
actually
asserted
in
the
context
of
some
third
party.
So
if
I
want
to
tell
you
that
I'm
licensed
to
drive,
probably
it'd
be
more
useful.
If
I
tell
you
that
the
state
of
texas
has
granted
me
the
license
to
drive,
if
I
want
to
tell
you
my
first
name
and
last
name,
you
probably
want
to
see
some
proof
of
that.
C
I
should
be
able
to
assert
information
about
myself,
like
maybe
I
want
to
be
authenticated
at
google,
so
I
think
it's
an
important
piece
of
the
puzzle,
but
I
think
it's
in
a
lot
of
the
stuff
that
you
want
to
know
really
needs
to
be
somehow
vetted
and
normally
vetting
has
to
happen
by
some
type
of
third
party.
That's
going
to
assert
information
about
you
so
when
you
say
no
formal
type
of
vetting
or
verification
that
almost
by
default
means
like
you're,
not
really
going
to
be
able
to
have
much
trust
in
this.
C
System
so,
and
by
the
way,
obviously
there's
going
to
have
to
be
for
so
there's
a
there's,
a
relation,
a
direct
relationship
between
trust
and
friction.
So
I
tell
a
story
actually
about
so
I
have
I
have
a
government
issued
id.
Let
me
pull
this
thing
out.
I'll
show
you,
so
I
have
one
one
of
these
smart
cards
issued
by
the
government.
It's
it's
a
doi
smart
card
department
of
interior
and
it
was
a
total
pain
in
the
ass.
To
get
this
thing
I
had
to.
C
First
of
all,
I
got
interviewed
by
the
fbi
at
my
office
and
I
first
I
filled
out
a
long
application.
Then
an
fbi
agent
came
to
interview
me
and
then
they
said.
Okay,
you've
been
approved
and
I
had
a
drive
to
temple
texas,
which
is
like
an
hour
north
of
austin.
In
order
to
get
basically,
they
took
my
photograph
and
my
fingerprints
and
they
said
okay.
Then
they
notified
me
a
month
later
and
they
said.
Okay,
you
can
come
pick
up
your
card
and
I
was
like
what
do
you
mean?
C
Can't
you
fedex
this
thing
to
me.
I
have
to
drive
an
hour.
You
know
two
hours
there
and
back
to
pick
up
the
card
and
but
actually
they
cannot
hand
me
the
card,
because
how
would
they
know
that
I'm
the
one
who
really
got
it?
So
when
I
went
to
pick
up
the
card
they
reinterviewed
me,
they
checked
my
high
resolution
fingerprints.
They
photographed
me.
They
handed
me
the
card,
so
that
process
has
a
lot
of
integrity.
C
So
so,
when
I
use
this
card
to
authenticate
they're,
pretty
sure
that
I'm
the
one
that
you
know
they
can
there's
a
chain
of
you
know
we
I
we
identity,
proofed,
you
and,
and
then
we
handed
you
this
card
and
unless
you
lost
that
card
we
can
be
pretty
sure
that
you're,
you
know
you're
the
one
on
the
other
side
of
the
terminal.
You
know
this
digital
connection,
so
so
you
can
reduce
every
time.
C
You
reduce
the
friction,
though
you
there's
a
compromise,
so
you
might
be
familiar
with
the
nist.
The
old
nist
level
of
loa
loa,
1,
loa,
2,
loa,
3,
so
loa
level
of
assurance.
Three
requires
that
you
well
level
level
of
assurance.
Two,
I
should
say,
requires
in-person
identity
proofing.
C
That
means
that
you
go
somewhere
present
your
id
to
a
person
that
person
looks
at
you
and
looks
at
your
id
says:
yes,
that's
you,
and
then
you
get
your
credential,
so
any
any
type
of
identity
system
that
doesn't
include
some
type
of
in-person
identity
proofing
would
be
limited
to
level.
One
assurance
level
level
three
requires
that
the
the
identity
credential
presented
is
checked
by
the
issuer.
C
So
I
have
to
show
my
driver's
license,
but
then
you
have
to
call
the
texas
state
department
of
public
safety
and
verify
that
this
is
actually
a
valid
driver's
license.
If
so
for
level.
Three,
you
have
to
verify
with
the
issuer
in
level
four
there's
even
more
requirements
on
identity
proofing
and
betting
and
verification.
D
So
a
couple
thoughts
on
that
one,
I
think,
like
part
of
that,
I
think,
is
like
what
you're
describing
is
identity
proofing,
which
is
effectively
tying
your
digital
identity
back
to
a
real
world
identity
which
has
sort
of
a
reputation
associated
with
it.
So
one
thing
that
we've
discussed
a
bunch
in
this
working
group
is
the
idea
that
you
can
establish
a
reputation
in
the
digital
world
separately
from
your
sort
of
physical
world
reputation
so,
for
instance,
just
with
the
raw
public
key.
D
D
So
I
think
that
that's
one
idea,
we've,
I
think,
talked
a
little
bit
about
and
then
another
is
making
the
probably
making
the
process
of
asserting
information
about
an
identity,
more
egalitarian,
I'm
using
the
right
word
there,
but
rather
than
sexualizing
the
authority
of
making
these
assertions
in
a
small
number
of
parties
having
you
know
an
ability
for
anybody
to
assert
about
anybody
which
is
sort
of
how
some
of
the
web
of
trust
models
work
right.
C
Yeah,
so
github
is
obviously
like.
Everyone
has
a
github
id
is
a
developer,
so
that's
a
good
centralized
identity.
It's
like
a
social
network
for
coders
I'd,
say
I
say
it's
a
social
network
where
you
can
check
in
code
and
and
rate
and
and
also
you
can
establish
your
your
your
credentials
through
your
history
of
commetce.
C
C
You
know
at
glue
we're
really
paranoid
about
this
being
a
security
company,
we're
concerned
like
are
there,
who
are
the
people
who
are?
Actually,
you
know
we're
working
with
and
glue's
very
virtual.
We
have
prior
people
all
over
the
world,
and
so
we're
always
concerned,
like
you
know,
is
this
guy,
a
russian
spy
for
example,
and
so
as
good
as
a
person's
commits
are
or
here's
another
prop
weird
problem.
C
We
had
a
couple
years
back,
we
were
hiring
on
on
upwork
and
the
guy
said
there
was
a
guy
who
said
he
was
ukrainian,
but
it
turned
out.
It
was
chinese.
C
So,
however,
great
that
guy's
you
know
commit
stream.
Is
it's
really
important
for
us
to
know
his
nationality
and
actually
his
nationality?
Being
chinese
wasn't
a
problem.
The
problem
was
that
he
lied
about
it,
so
that
creates
a
trust
problem
for
us,
and
so
you
know
in
in
in
when,
when
I
talk
about
digital
identity,
there's
this
impedance
mismatch
between
analog
and
digital
systems,
whereas
a
analog,
carbon-based
life
form.
C
So
so
to
me,
digital
identity
is
about
how
do
we?
Actually?
How
are
we
ultimately
able
to
map
back
a
a
a
digital
identity
back
to
a
real
person
and,
and
then
what
do
we
know?
What
do
we
know
about
that
person
or
who
knows
about
that
person?
I
maybe
don't
need
to
know
about
that
person.
I
don't
maybe
don't
need
to
know
who
that
person
is.
C
If
I
trust
somebody
who
says
they
do
so
in
open
id
connect,
we
have
this
thing
called
pairwise
identifiers,
where,
if
I,
my
idp
google,
let's
say,
doesn't
tell
you
what
my
gmail
address
is
or
google
doesn't
do.
This
is
a
bad
example,
but
let's.
B
C
If
you
have
an
idp,
that's
more
privacy
conscious,
you
could
just
release
it
with
a
pairwise
identifier,
which
would
be
different
for
every
website.
So
if
I
log
into
let's
say,
abc.com
has
my
idp
and
I
go
to
website
one
two
and
three:
my
idp
would
release
a
different
username,
basically
for
each
website,
and
that
way
it
can't
be
correlated
around
these
websites
in
saml.
We
call
this
persistent
non-correlatable
identifiers
in
open
id.
It's
called
pairwise
identifiers.
C
So
in
a
way
I
don't
really
sometimes
I
don't
need
to
know
so
in
the?
U,
let's
take
university
setting,
so
let's
say
the
university
decides.
I
don't
want
really
need
to
tell
this
website
who
the
person
is.
I
only
need
to
tell
them.
This
is
a
student
at
my
university,
so
let's
say
you're
doing
research
online
and
you
want
to
read
how
to
build
a
nuclear
bomb
and
you're.
C
Like
I'm
curious,
I'm
academically
curious
how
hard
it
is
to
find
out
this
information,
but
you
don't
want
to
search
how
to
search
a
new,
how
to
build
a
nuclear
bomb
unless
the
fbi
show
up
and
start
asking
you
questions
so
from
the
university
perspective.
The
right
of
the
person
to
research,
whatever
the
heck
they
want,
should
be
maintained,
because
you
can
go
to
the
library
and
read
books
and
there's
no
trail
and
no
one's
going
to
be
asking
you
why
you're
reading
these
books
and
they
want
to
maintain
that
in
the
digital
world.
C
So
this
is
a
good
use
case
for
pairwise
identifiers
and
so
from
the
from
the
content
provider
perspective.
They
have
valuable
content
right,
they're,
giving
you
published
books,
and
they
want
to
know
that
they
only
want
to
allow
you
access
to
this
published
content
if
you,
if
you're,
buying
a
license
from
them.
But
from
from
the
university's
perspective,
I
don't
need
to
tell
you
who
the
person
is.
I
just
need
to
tell
you.
C
This
is
a
student
at
my
university
and
my
university
has
a
license
to
your
content,
and
so
so
I
think,
but
ultimately
should
something
bad
happen.
So
let's
say
it
turns
out
that
that
wasn't
a
student
it
was
actually
a
terrorist.
C
Then
we
still
want
some
accountability,
some
way
for
the
publisher
to
say.
Well,
you
know
this
transaction,
where
you
said
we
didn't
know,
we
didn't
need
to
know.
Well,
actually
we
have
a
subpoena
and
we
need
to
know
who
it
is.
So.
Can
you
help
us
figure
this
out?
So
so
the
trust
between
the
university
and
the
publisher
could
be
sufficient.
C
So
I
think
this
is
why
I
always
talk
about
trust
and
inter-domain
trust
as
as
as
so
important
because
it
turns
out,
it
was
really
easy
for
us
to
connect
on
the
internet.
We
figured
that
out
in
the
90s,
but
we
didn't
figure
out
how
to
create
trust
between
domains
and
that's
been
left
to
I
mean
in
a
large
part,
social
networks
and
consumer
idps
have
filled
that
gap,
but
it's
a
really
really
tough
problem
and
I
think
individuals
have
been
kind
of
screwed
in
the
process
because
they
don't
have
economies
of
scale.
C
C
So
we
have
a
lot
of
these
bad
deals
where
we
can
either
take
it
or
leave
it
contracts
right.
So
I,
what
am
I
feeling
is
really
been
is
that
consumers
lack-
and
this
goes
for
developers
too-
they
lack
economies
of
scale
in
negotiating.
You
can't
negotiate
with
github
on
their
privacy
agreement.
You
can't
even
read
their
privacy
agreement.
C
It's
too
long
so,
where
I
feel
like
federations
could
help,
is
that
federations
could
perhaps
give
collective
bargaining
power
to
a
group
of
individuals,
so
self-sovereign,
identity
or
web
of
trust
type
of
ideas
are
technical
solutions,
but
actually
it's
not
just
the
the
tools
that
you
need.
You
also
need
rules
in
order
to
convey
valuable
information
that
creates
trust
and
and
federations
provide
an
opportunity
to
create
economies
of
scale
that
work
for
the
consumer.
C
A
good
example
I
like
to
give
is
remember
consumer
reports,
so
I
don't
know
if
people
read
magazines
anymore,
but
so
individual
consumers
don't
have
the
time
to
like
review
products,
but
by
pitching
in
like
12
a
year-
and
you
know
millions
of
people
do
that
and
then
consumer
reports,
the
consumer
union,
can
review
products
or
another
good
example,
is
the
idf
in
israel
has
a
buyer's
club
and
because
they
have
such
a
large
percentage
of
the
population.
C
So
if
you
want
a
mobile
phone
contract
in
israel,
you're
better
off
buying
that
through
the
idf
buyers
club,
because
if
you
have
a
problem
with
a
telephone
company
as
an
individual
you'll,
have
a
lot
less
bargaining
power
than
if
you
go
to
your
idf
buyers,
club
and
let
them
deal
with
the
telco
for
you.
So
I
think
we
need
the
federations
create
an
opportunity
for
to
get
more
collective
bargaining
power
to
individuals
and
to
organizations.
C
But
what
we've
seen
is
is
that
actually
federations
are
hard
to
form,
and
so
so
large
consumer
idps,
it's
easier
to
build
a
centralized
trust
model.
So
it's
easier
to
build
a
google
or
a
github
or
a
facebook
than
it
is
to
figure
out
how
to
get
google
and
facebook
to
collaborate
and
github
to
collaborate.
C
So
I
really
feel
like
we're.
At
the
I
mean
I
hate
to
be
pessimistic,
but
but
I
really
feel
like
this
is
not
gonna
be
solved
in
my
lifetime
like
we're
building
building
blocks
here,
but
I'm
I'm
really
pessimistic
about
our
ability
to
solve
this
trust
problem
like
I
think
it
will
get
solved.
But
I
think
it's
gonna.
C
Take
like
a
hundred
years
of
law
of
a
combination
of
law
technology
enough
problems,
bad
enough
for
people
to
realize
that
we
have
to
actually
do
something
and
it's
just
a
complete,
complete
mess
right
now
this
morning,.
E
I'm
new
to
this
working
group,
so
I
apologize
if
this
this
question
is
too
basic,
but
is
the
is
the
goal
here
to
replace
the
identity
provider
of
systems
like
github
or
package
managers
like
pi,
pi
or
npm,
or
is,
or
or
maybe
another
way
to
look
at
it
is
like?
Could
we
ask
those
providers
to
provide
us
some
indication
of
the
trustworthiness
of
the
user
like
do
they
have
multi-factor
authentication
set
up
some
of
their
contribution?
E
History
is
public,
some
might
be
private,
but
that
you
know
it
seems
to
me
it
would
be
a
large
undertaking
to
ask
all
these
systems
to
replace
their
identity
providing
systems,
but,
but
maybe
there's
a
way
to
get
signal
from
their
existing
systems.
To
help
inform
that
question
of
like
how
trustworthy
is
a
user.
C
Yeah
yeah,
no,
I
don't
think
replace
at
all,
so
take
the
npm,
committers
or
github
community.
I'd
say
each
of
these
are
basically
well,
I
would
say,
they're
actually
participating
they're,
potentially
participants
in
a
federation
right
now,
they're
really
autonomous
domains
that
have
their
own
policies
about
user
management.
How
do
they
onboard
users?
What
betting
process
did
they
use?
What
type
of
authenticators
do
they
issue?
What
are
their
security
policies
so
each
they're?
C
Actually
each
one
of
those
guys
is
more
like
one
of
these
circles
here
where
they're
an
individual
participant
right
now
there
is
no
federation
so
right
now,
if
you
want
to
take
your
npm
credentials
and
go
to
github,
there's
probably
no
way
to
do
that,
but
so
I
think
like
it
would
be
perhaps
interesting
to
think
about
forming
a
federation
that
defines
some
common
tools
and
rules
around
digital
identity,
and
then
that
would
perhaps
enable
interoperability.
C
That's
another
goal
is
how
do
I?
Maybe
I
don't
want
a.
I
already-
have
an
identity
at
github.
So
why
do
I
need
another
identity
at
in
in
npm?
And
so
can
I
bring
my
my
identity,
so
the
federation
can
facilitate
interoperability
and
really
the
federation
builds
trust.
C
So
if
I'm
npm,
how
do
I
know
I
can
trust
an
identity
from
github
and
the
federation
can
define
you
know
legally
how
how
that
trust
can
work
so
right
now,
what
you
have
is
a
lot
of
autonomous
domains
with
no
federation
and
therefore
no
trust
between
the
domains.
C
But
I
don't
believe
that
I
I
think
that
so
we're
gonna
always
have
each
each
domain
ultimately
needs
to
be
responsible
for,
even
if
I
don't
have
a
password
in-
let's
say:
let's
take
the
github
npm
example.
Even
if
I
don't
have
a
credentials
in
npm,
I
still
need
an
account
in
npm
because
they
need
to
track
me
and
they
have
their
own
permissioning
system.
C
So
we're
never
going
to
stop
each
domain
from
holding
a
digital
from
holding
accounts.
C
What's
in
those
accounts,
whether
they
have
credentials
associated
with
them
like
passwords
or
other
to
phyto
tokens
or
whether
they're,
using
a
pointer
to
credentials
that
somewhere
else
or
what
you'd
say
hold
about
that's
another
question
and
by
the
way
one
of
these
circles
could
be
self-sovereign
identity.
C
So
if
you,
if
you're,
perhaps
your
own
identity
provider
or
you're
using
some
type
of
decentralized
identity,
you
know,
maybe
this
is
a
did
a
reference
to
the
id
and
and
but
if
you
want
to
use
that
did
at
a
site,
you
maybe
also
need
some
normalization
of
trust.
Does
that
answer
your
question.
E
Yeah
partially,
I
guess
I
yeah,
I
guess
it's
a
it's
a
big
question.
That's
that's
a
good
way
to
think
about
it,
though.
B
Let
me
jump
in
here
a
little
bit
because
I
think
there's
two
different
kinds
of
questions.
One
is
what
what
is
this
group
doing?
I
can
make
an
attempt-
and
somebody
tell
me
if
I'm
wrong,
but
my
interest.
You
know
this
group.
B
The
longer
goal
is
being
able
to
verify
that
you
know
when
a
developer
does
something
and
signs
or
something
we
could
basically
being
able
to
verify
an
attestation
that
a
certain
developer
did
something,
and
what
we've
been
doing
is
inviting
people
to
speak
about
various
identity
issues
so
that,
as
we
drill
into
the
actual
solution,
we'll
have
a
better
understanding
of
different
viewpoints.
So
we're
kind
of
in
the
information
gathering
phase
right
now
right.
B
And
we're
we're
hoping
that
this
sort
of
thing
will
will
help
us
come
up
with
solutions
that
work
for
a
variety
of
circumstances,
including
in
particular
we're
gonna
have
to
deal
with
federations.
B
C
You
know
another
word
for
federation
is
trust
framework,
so
I
I
use
federation
because,
but
it
is
sort
of
like
it's
a
very
geeky
word.
That
means
different
things
for
different
people,
so
I
I
also
hear
people
say
trust
framework,
sometimes-
and
I
I
think
federation
I'll
tell
you,
there's
another
interesting
federation
to
look
at
called
open
banking.
C
Open
banking
is
basically
the
uk
government
said
that
all
banks
need
to
offer
common
apis
for
payments
and
for
account,
balance
and
stuff
like
that,
and
so
open
banking
was
basically
a
government
agency
where
the
uk
government
said
okay,
if
you're
a
bank,
you
have
to
be
in
open
banking,
so
it
was
mandated
a
lot
of
times.
Federations
get
formed
because
by
because
banks
didn't
have
any
choice.
The
uk
government
said
if
you're
a
bank-
and
you
want
a
banking
license.
C
You
have
to
do
this,
but
it's
an
interesting
example
of
a
federation
because
so
you
have
basically
banks
who
are
each
bank
is
autonomous.
They
have
their
own.
This
is
obviously
a
very
high
trust
federation
by
the
of
course,
but
there's
really
really
good
information
on.
If
you
want
a
good
example
of
two
of
tools
and
rules,
it's
very
well
documented.
C
I
think
the
uk
government
spent
like
70
million
dollars
building
this
federation,
so
they
have
some
really
advanced
ideas
about
things
like
software
statements,
which
is
you
know
so
everyone's
familiar
with
oauth,
how
you
get
a
client
id
in
secret.
A
software
statement
is
like
a
jwt
that
the
developer
presents
in
order
to
get
client
credentials.
C
A
lot
of
like
countries
are
going
to
use
this
as
a
basis
for
building
federations.
You
know,
so
I
think
you
know
what
you
have
to
figure
out.
You
know
based
upon
your
goals,
let
me
find
your
home
page
again,
so
so
I
think
that
what
you
could
do
to
move
the
ball
forward.
A
little
bit
would
be
to
build
some
type
of
trust
framework
that
now
that
so
people
would,
or
companies
or
individuals
would
have
to
opt
into
this
trust
framework.
C
The
hard
thing
about
trust
frameworks
is
always
the
governance
of
the
trust
framework.
I'll
give
you
an
example
of
a
trust
framework
that
failed.
C
The
project
the
federation
actually
failed
because
at
boeing
they
fund
projects,
they
don't
and
the
federation
wasn't
something
when
they
can
say
when
it
would
end
so
they're
like
okay,
so
we're
going
to
fund
this
project
for
two
years,
but
at
the
end
of
two
years,
we're
going
to
still
need
a
federation
that
does
this.
So
it
was
like
a
project
that
had
no
end
even
income
and
struggles
to
keep
sort
of
the
in
commons
been
around
for,
like
maybe
15
years
or
so.
C
C
That
becomes
a
real
challenge
around
trust
frameworks,
we're
trying
to
actually
build
another
federation
in
the
motor
vehicle
space
right
now.
So
a
lot
of
states
are
want
to
move
to
digital
driver's
license.
C
C
C
That's
that's
gonna
looks
like
they're
gonna
serve
as
the
federation
operator
and
they're
funded
by.
They
have
continued
funding
by
motor
vehicles.
So
so
one
of
the
challenges
I
think
you're
going
to
face,
though,
is
is
you
can
define
a
trust
framework,
what
it
would
be,
what
are
the?
What
are
the
tools
and
the
rules?
So
what
is
the
minimum
amount
of
rules
that
you
can
define?
C
How
do
you
disclose
whatever
you're
going
to
disclose?
Are
you
going
to
use
trust
marks?
Are
you
going
to
use
something
else,
and
is
the
federation
gonna
have
any
infrastructure?
Is
it
gonna
publish
so
one
of
the
one
of
the
actually
in
in
we
had
propose
a
standard,
a
cantara
called
auto,
and
this
was
how
do
how
do
you,
what
are
the
apis
to
publish
federation
metadata?
C
So
I
we
we
actually
ended
up
giving
up
on
this
standard
because
it
we
didn't,
have
a
federation
that
was
ready
to
implement
it
and
you
need
adoption.
Adoption
is
more
important
than
actually
than
writing
the
standard.
So,
but
what
are
the?
How
do
you,
let's
say,
you're,
a
participant
of
the
federation
and
you
need
to
update
your
keys?
C
Is
there
an
api
that
you
call
or
let's
say
you
need
to
so
so:
what's
the
infrastructure
of
the
federation,
what
are
the
apis
like
the
open
banking
has
a
way
that
you
can
update
your
infrastructure.
Your
information
with
them
in
common
has
a
website
where
you
can
update
your
information
with
them.
So
what
are
what?
What
type
of
infrastructure
are
you
going
to
use
to
to
implement
this
trust
model
and
who's
going
to
operate,
that
infrastructure
forever?.
C
So
yeah
yeah,
and
then
I
guess
your
other
question
is
you
know,
is
where
are
you
going
to
compromise?
C
So
you
know,
I
think
that
in
order
to
achieve
like
valuable
work,
you're
going
to
probably
need
to
include
vetting
and
verification,
but
I
think
that
the
your
position
should
maybe
be
more
flexible
and
say
that
we're
going
to
support
a
range
of
trust
models.
So
what
they
figured
out
in
the
police
federation
was
that
it
would,
if
everyone,
if
we
say
that
everyone
is
going
to
have
to
be
level
four,
there
was
like
30
organizations
that
could
join,
but
by
relaxing
the
the
requirements
around
verification
and
vetting
we
can
get.
C
So
what
I
would
say
is
is
that
don't
throw
out
vetting
and
verification,
because
that
will
limit
the
usefulness
of
your
work
for
high
security
and
high
value
software,
and
but
don't
say
that
just
because
maybe
you're
an
organization
that
doesn't
do
any
vetting
or
verification,
maybe
I
don't
care.
If
I'm
writing,
let's
say,
maybe
a
chess
playing
algorithm.
C
Maybe
I
don't
really
need
to
know
the
identity
of
somebody.
I
don't
care
if
they're,
russian
or
chinese,
but
if
we're
writing
security
software
like
the
jansen
project,
maybe
we
really
do
need
to
know
who
everyone
is
and
because
that's
going
to
be
used
for
government
and
military
and
and
we
need
to
maybe
have
more
a
stronger
process
in
order
to
to
write
this
type
of
infrastructure
software.
So
anyway,
it's
really
gargantuan
path.
I
don't
know
if
you
know
what
you're
trying
to
do
and
how
difficult
it
is.
A
Yeah
you,
you
bring
up
a
lot
of
good
questions,
a
lot.
A
Think
about,
unfortunately,
I
just
looked
at
the
clock.
I
didn't
even
realize
we
were
at
time
now.
This
has
been
super
interesting
and
valuable.
I'm
looking
forward
to
going
back
and
actually
watching
the
recording
a
bit
more,
I
think
yeah
I
mean
I
would
love
to
continue
this
discussion
since
we
ran
out
of
time
today,
but
I
don't
know,
michael
if
you'd
be
willing
to
join
us
again.
There
might
be
more
questions
here
or
yeah.
It'd
be
super
interesting
to
talk
about
this
a
bit
more.
C
A
little
bit
technically,
I'm
not
traveling
these
days,
so
that's
kind
of
sitting
at
home,
so
yeah
yeah,
thanks
for
the
invitation
and
yeah.
Just
let
me
know
I
can,
if
I
can
provide
some
tactical
help
and
chapter
10
of
my
book
is
actually
not
a
bad
place
to
start.
You
awesome.