►
Description
Topics covered
-----------------------------
0.40 - Guest’s introduction
3:43 -Presentation Overview
4:10 - SIWE
6:29 - EIP-4361 (History)
7:19 - Purpose
8:10 - Specification
11:05 - Will "Sign in Ethereum" may also be working with oAuth in future?
14:26 - EIP-191 Vs. EIP-712, ABNF conformance,
19:27 - EIP-1271 Compliance
22:23 - Recommended resolution of ENS data
24:59 - Guidelines
27:53 - Additional rationale
28:14 - Security consideration
34:54 - Community involvement
36:18 - Community call - top discussion points
36:43 - login.xyz - a home for EIP-4361
37:02 - Support
38:12 - Next steps
Q&A
39:50 - Do you see this playing a role in the authentication space where a hardware wallet could authenticate everything in a way a key could?
41:24 - Does the implementation of signin with Ethereum require that wallets maintain their own code or is it as simple as updating a package?
44:50 - Traceability of account, is that possible with the present architecture of SIWE?
47:31 - Are there any fees involved, monthly or per usage?
48:11 - Is there anything that might be limiting for Signin Ethereum to be used with Metamask Snap?
49:49 - Does this pave the wave for users to be able to sign into a website without having to install a browser extension? How could this be a UX improvement for a centralized exchange user coming over to a DeFi space?
53:01 - Would it be possible or any further support extending the Sign-in with Ethereum to physical assets that have some communication layer like WiFi, Bluetooth?
54:25 - “Attaching an identity to a private key” - Do you see this as a concern or has it been addressed already?
55:23 - Reference implementation not inline with spec, has it already been addressed?
56:40 - Dependency of 1328 on the EIP-4361?
58:04 - Readiness of the proposal
Resources:
-----------------
- EIP - https://eips.ethereum.org/EIPS/eip-4361
- Discussion-to - https://ethereum-magicians.org/t/eip-4361-sign-in-with-ethereum/7263
- Website - https://spruceid.com/
- Docs - https://docs.login.xyz/
- Blog - https://blog.spruceid.com/sign-in-with-ethereum-january-updates/
Follow at Twitter
-----------------------------------------------
Wayne Chang @wycdd | William Schwab @William94029369 | Alita Moore @AlitaMoore85 | Pooja Ranjan @poojaranjan19
ERCs playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqXee9EMQDIEz2CslTnsW0K
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/EthCatHerders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Welcome
back
to
p
paneer
an
educational
video
series
where
we
learn
about
an
ethereum
improvement
proposal,
upcoming
upgrades
and
the
basics
of
ethereum
blockchain,
I'm
puja
ranjan,
and
today
we
are
going
to
talk
about
eip
4361
sign
in
to
talk
about
the
proposal
we
are
joined
by
wayne.
Chang
wayan
is
a
chief
intervention
officer
at
spruce,
heidi
and
is
one
of
the
co-authors
of
the
proposal.
B
A
A
It
was
documented
in
october
last
year
and
is
currently
in
draft
status.
However,
there
is
an
open
pull
request
for
it
to
be
moved
to
the
review
status,
we'll
get
to
know
more
about
the
proposal
and
about
the
status
in
this
episode.
Signing
with
ethereum
sounds
intriguing
and
I'm
looking
forward
to
learning
more
about
the
proposal.
B
Yeah,
of
course
I
have
slides.
I
can
share
after
this
brief
intro,
but
yeah.
So
my
name
is
wayne.
I'm
working
on
spruce,
spruce
has
been
around
for
almost
a
year
and
a
half.
Now
we
focus
exclusively
on
decentralized
identity.
The
idea
of
letting
users
control
their
data
across
the
web.
We
think
that
public
private
key
infrastructure
is
probably
one
of
the
best
ways
to
do
it
technologically,
and
you
know
I'd
say
that
ethereum
and
evm
compatible
systems,
probably
the
most
successful
one.
B
We've
seen
to
date,
really
excited
to
figure
out
the
potential
there,
and
before
that
I
worked
at
a
company
called
consensus,
also
working
on
decentralized
identity.
Actually,
when
we
were
exploring
decentralized
networks
and
trying
to
figure
out
how
to
make
more
things
more
peer-to-peer.
One
of
the
big
problems
that
came
up
over
and
over
again
was
identity,
because
if
you
look
at
a
lot
of
the
centralized
platforms
today,
they
actually
serve
an
important
purpose,
providing
trust
for
interactions.
B
We
think
that
data
must
also
move
decentralized,
so
you
can
know
that
someone
has
a
valid
driver's
license
or
you
know
they
have
a
good
reputation
on
the
network
and
before
you
step
into
their
car
right.
So,
ideally,
you
know
this
doesn't
happen
through
an
omnibus
kind
of
provider,
but
instead
it
happens
to
peer-to-peer
just
like
the
transactions.
B
A
B
Okay,
great,
let's
dive
in
so
we're
going
to
go
over
an
overview
of
the
project.
What
we're
trying
to
do
with
it
history
of
the
project,
how
it
got
formulated
in
the
first
place,
the
review
of
the
spec
itself
we're
going
to
go
over
a
laundry
list
of
security
considerations.
There
are
a
lot
of
them
and
we
take
them
seriously.
B
B
so
signing
with
ethereum
we
abbreviate
as
seaweed
as
in
c
yes,
and
we
we
are
gonna,
make
it
in
fact
we're
trying
to
do
a
cute
like
seaweed
and
a
seaweed
inspired
logo
for
it.
But
you
know,
hopefully
we
can
get
to
that
soon.
It's
a
new
form
of
authentication
that
lets
users
control
their
digital
identity,
with
their
ethereum
account
and
enos
profile
instead
of
relying
on
a
traditional
intermediary.
B
What
if,
instead,
you
could
sign
in
with
your
ethereum
account
that
you
already
have
and
if
you're
an
ethereum
user
you're,
probably
pretty
decent
at
managing
your
keys
already,
if
you
have
digital
assets
that
you
use
and
if
you're
not,
you
should
learn
how
and
basically
you
can
also
use
those
keys
for
other
things
than
sending
assets
around
or
interacting
directly
with
smart
contracts.
What,
if
you
could
sign
an
authentication
request
to
log
into
a
service
right?
That's
the
whole
idea
behind
signing
with
ethereum.
It's
not
a
new
idea.
B
It's
been
in
production
for
years.
I
think,
if
you
look
at
opencv,
for
example,
you
try
to
go
to
your
profile
for
your
account.
You
try
to
edit
some
details
about
yourself.
Basically,
openc
doesn't
want
you
to
edit
your
details
until
you've
proven
that
you're,
actually
the
person
behind
that
account
right
and
how
you
do.
That
is
signing
a
login
message
after
you
connect
your
wallet
and
then
you
can
get
an
authenticated
session
and
you
can
update
the
stuff.
B
Basically,
you
we
have
everything
from
really
nice
requests
with
issued
at
times
and
challenges
or
nonces
to
prevent
replay
attacks
to
things
that
were
just
like
blogging
in
all
caps
right
and
they
made
the
user
sign
that
or
even
worse.
It
was
like
a
random
hash
message
that
the
user
couldn't
possibly
get
any
idea
around
and
they
were
expected
to
sign
this
and
it
would
do
things
right
and
that
that
is
highly
suspicious,
because
when
the
user
doesn't
know
what
they're
signing
that
you
know
all
sorts
of
problems
from
there.
B
B
Libraries
spruce
submitted
a
proposal
and
fortunately,
arts
was
accepted.
So
we
started
the
work
late
last
year
and
basically,
the
purpose
is
to
provide
a
self-custody
alternative
to
centralized
identity
providers
for
the
users
who
want
it
and
with
an
increase
in
control.
Users
do
accept
an
increase
in
responsibility,
because
if
you
lose
your
key,
it's
very
problematic.
B
There
are
ways
to
make
this
better,
but
that's
a
whole
industry-wide
issue
that
a
lot
of
people
are
working
on
and
we
just
think
that
there
are
certain
incentive
compatibilities
that
you
can
enable
better
if
the
user
has
a
direct
authentication
relationship
with
the
service.
Instead
of
going
through
an
intermediary
right,
if
especially
if
the
intermediary
you're
going
through,
you
know
likes
to
make
money
off
of
the
information
they
collect
on
you
or
you
know,
try
and
influence
your
behavior
in
other
ways.
B
We
must
prefer
this
kind
of
peer-to-peer
mode
of
interaction
and
that's
why
we're
really
interested
in
working
on
this,
so
we're
really
fortunate
to
have
worked
on
it.
So
what?
What
is
the
specification?
What
does
it
do?
It's
actually
pretty
like
tightly
scoped,
we
believe
in
solving
one
small
problem
at
a
time.
This
is
a
very
important
small
problem,
but
we
try
to
reign
it
in.
We
see
a
lot
of
attempts
at
these
overarching
identity
systems
like
this
is
how
the
world
could
work.
B
You
need
to
adopt
these
emerging
standards
and
everything
we
were
kind
of,
like
generally,
not
so
excited
by
that
direction,
because
usually,
when
you
make
someone
have
to
buy
a
whole
ecosystem
just
to
get
any
value
out
of
something,
it's
really
difficult
to
get
adoption,
and
this
is
something
that
you
really
need
network
effects
to
be
effective.
So
what
did
we
do?
B
I
think
that
there
is.
There
is
a
narrative.
I
wanted
to
spell
that
people
think
that
you
know
you
know
your
identities
can
be
fully
represented
as
nfts
in
the
blockchain.
I
think
that's
really
untrue.
Nfts
might
be
good
for
some
public
facets
of
people's
lives
or
informations
or,
but
I
think
private
is
the
right
place
to
start
for
people's
data
and
extremely
selectively
revealing
what
they
want
to
disclose
to
the
public.
B
That's
how
we
achieve
privacy
and
so
making
sure
that
we
have
room
in
the
spec
to
extend
for
these
use
cases
as
well.
It's
very
important
to
our
work
and
message
looks
like
this.
It
is
not
too
different
than
some
of
the
specifications
not
specifications,
but
implementations
we've
seen
in
the
wild
intentionally
so
again
trying
to
balance
that
act
between
what
the
user
sees
and
what
is
machine
readable
for
people
used
to
some
more
established
technologies
like
jwts
json
web
tokens
defined
ietf,
you'll
notice
that
this
is
actually
like
a
specialized
gwt.
B
We
have
even
very
similar
field
names
issued
at
expiration
time
not
before
and
also
are
able
to
specify
a
non-prevent
replay
attack.
So
this
is
the
general
message
format
and
you
can
have
some
variations.
Certain
fields
are
optional
again
to
improve
readability,
but
it's
required
to
be
displayed
in
certain
order.
C
B
You
know
it's
kind
of
one
big
product
discussion
nightmare,
but
if
you
have
a
very
specific
thing,
it's
much
easier
to
talk
about
and
with
respect
to
oauth
or
open
id
connect.
Part
of
the
deliverables
actually
was
an
identity
provider
server
implementation
that
was
compatible
with
openid
connect
and
we've
also
implemented
that
in
rust.
B
So
the
challenge
here,
though,
with
the
current
open
id
connect
specification
as
it
stands
today
and
if
you
ever
click
sign
in
with
google
and
get
redirected,
you
know
that
that's
openid
connect
working
under
the
hood.
I
think
facebook
technically
does
not
use
openid
connect
just
uses
oauth
too,
with
some
custom
claims
on
top
or
something.
B
B
That
way,
right
so
to
make
it
really
easy
for
people
who
only
want
to
integrate
support
for
signing
with
ethereum,
like
that,
we
think
a
good
middle
of
the
ground
solution
is
to
figure
out
how
to
get
a
non-profit,
a
foundation,
some
kind
of
credibly,
neutral
entity
to
actually
run
an
instance,
a
secured
instance
of
an
identity
provider
server
so
that
there's
no
incentive
misalignment
with
the
user,
and
if
the
user
trusts
this
intermediary,
then
you
know
they
can
decide
to
use
that
service.
But
we
do
recommend
direct
authentication
where
possible.
B
So
some
things
we
wanted
to
talk
about
eip191
versus
eip712
was
an
important
decision
made
abnf
conformance
why
we
picked
that
and
also
eip1271
compliance,
so
I'll
go
over
what
give
a
refresher
on
what
each
of
these
things
are
and
kind
of
talk
about
how
they
relate
to
this
spec
when
you're
signing
stuff
with
ethereum
most
people
will
sign
ethereum
transactions
that
are
interpreted
by
the
blockchain,
as
you
know,
a
valid
transaction
on
their
network,
and
it
will
do
things
interact
with
smart
contracts,
etc.
Right.
What?
If
you
want
to
sign
stuff?
B
B
So
you
can
sign
something:
that's
not
a
transaction
for
sure
right
and
then
it
did
not
specify
what
happens
after
that
eip
712
not
to
be
confused
with
eip
721,
which
is
the
nft
standard.
But
712
specifies
structured
types
for
data
signing,
and
this
is
actually,
I
think,
on
top
of
one
on
one
in
many
implementations
where
we
are
defining
how
to
create
fields
to
sign
right
like
if
we
want
an
expiration
field.
B
Wherever
possible,
you
should
lean
towards
a
more
structured
data
format,
because
it's
tighter
there's
less
room
for
error
and
less
room
for
multiple
interpretation
which
leads
to
security
bucks.
There
was
a
format
called
xml
dseg,
and
you
know,
because
there
were
multiple
formats
of
it.
That
could
come
to
the
same
signature
right
and
verify
that
the
same
way
there
were
classes
security
bugs
introduced
because
of
this
ambiguity
and
flexibility
in
the
format.
B
B
But
we
found
that
when
we
tried
to
display
the
ip712
message
to
wallets
today
we
have
a
whole
research
report
on
this.
It's
basically
really
difficult
for
the
user
to
understand
what
they're
doing
it
just
barfs
out
on
many
wallets
like
a
json
blob
that
has
a
huge
eip,
712
header
that
doesn't
contain
any
information
about
the
signing,
just
some
kind
of
like
setup
work
for
this
of
the
type
data
structures
right,
and
we
found
this
to
be
pretty
horrible
from
a
ux
perspective.
B
B
Far
worse
than
you
know
what
they
already
had,
and
that
would
just
kind
of
be
a
non-starter
for
a
lot
of
these
applications,
and
then
you
have
this
cold
start
problem
where
oh
well,
if
we
get
the
wallets
to
talk,
eip712
and
display
it
nicely,
then
maybe
they'll
revisit,
but
who's
using
this
on
the
application
side
asks
the
wallets.
You
know,
so
you
have
a
big
cold
start
problem
with
that.
That's
why
we
did
two
things.
We
decided
to
go
with
three
things:
actually
we
decided
to
go
with
eip191.
B
We
added
a
version
field
as
part
of
the
message
format
for
this.
So
right
now
we're
in
version
one.
We
go
to
version
two
in
a
world
where
eip712
is
everywhere
and
abundant
in
great
ux
and
wallets.
Then
you
know
that's
something
that
we
consider
for
version
two
but
version
one
will
always
be
ip101,
and
this
plain
text
message
we've
rigidly
defined
in
abn
f,
and
this
is
a
grammar
specification
at
iutf.
It's
been
used
over
30
years
in
a
bunch
of
other
specifications
and
basically
it
lets.
You
define
rigidly
this
message.
B
Format
saying
things
like
this
thing
must
be
a
uri.
This
version
must
be
a
number.
You
know
we
are
particular
about
the
new
lines
and
how
many
new
lines
you
have
to
have,
after
a
statement
even
down
to
the
format
of
like
an
ethereum
address
right.
So
that
is
how
we're
making
the
compromise
between
something
the
user
can
understand
and
something
that
the
machine
can
unambiguously
read
and
make
sure
that
we
have
those
increased
security
properties,
so
eip
1271
compliance
as
well.
B
So
what
is
eip1271
well,
it
is
basically
a
standard
for
smart
contract,
signature
validation,
and
what
does
that
mean?
It
means
that.
So
you
want
to
sign
messages
and
you
have
a
key
okay
cool.
That's
great,
just
sign
the
message
right:
what,
if
you're
a
smart
contract-
and
you
don't
want
to
put
a
private
key
in
the
smart
contract,
because
then
everyone
can
see
it
right.
So
how
does
a
smart
contract
sign
things
or
validate
that
it's
a
good
signature
produced
right
and
eip?
1271
is
a
standard
that
basically
is
supported
by.
B
I
believe
argent
wallet,
gnosis,
safe
and
a
few
others
as
to
how
to
validate
a
signature
with
a
smart
contract.
It
is
theoretically
gasless
because
it's
an
rpc
get
call
right.
So
you
it's
read
only
and
it
requires
you
to
define
one
function
called
is
valid
signature.
Where
you
pass
a
hash
of
the
message.
The
signature
and
it'll
tell
you.
If
it's
valid
or
not,
that's
it
right.
So
you
can
imagine
how
to
implement
this
with
a
multi-sig
right.
B
B
B
Key
management,
we'll
talk
about
in
the
security
considerations,
section
more,
but
it's
probably
one
of
the
most
important
problems
for
the
whole
industry
to
solve,
and
we've
seen
great
progress
over
the
past
10
years,
basically,
people
being
able
to
manage
their
keys,
some
of
the
most
innovative
solutions
around
improved
key
recovery.
In
case
you
lose
your
keys.
B
What
happens
right
uses
multi-sigs
and
many
of
them
use
eip1271
as
well,
so
having
the
benefit
of
being
able
to
rely
on
the
really
quickly
growing
ecosystem
of
key
recovery
solutions
based
on
contract
signing
you
know,
that's
really
exciting.
We
definitely
wanted
to
support
that
in
the
spec.
We
think
that's
really
great
advances
in
coming
with
respect
to
ux
and
security,
so
we
believe
that
sessions
should
be
bound
to
key
material
and
not
necessarily
ens
data,
but
we
encourage
the
resolution
of
enos
data
to
load
a
user's
profile.
B
If
that's
how
they
expect
to
interact
with
you,
so
after
a
user
authenticates
or
even
before,
you
know
they
just
connect
wallet,
you
see
that
they
claim
to
have
a
certain
address,
but
you're
not
sure
that's
really
them
right.
Signing
with
ethereum
is
different
than
just
clicking
the
connect
wallet
button,
because
when
you
do
that,
all
it
does
is
reveal
you
know.
I
have
this
address
right
and
anyone
can
write
a
browser
extension
that
implements
the
same
api
and
just
can
claim
they
have
any
address
right.
B
So
that
alone
is
not
enough
to
authenticate
a
user
for
services.
You
want
to
do
something
more.
You
want
to
do
sign
in
with
ethereum
after
connect
wallet,
if
you
want
that
authenticated
session,
so
it
can
happen
before
and
after,
but
the
semblance
of
it
happening
after
is
that
you
get
to
see
that
oh,
this
is
authentically
the
user.
You
can
start
deciding
to
give
access
to
someone
if
they
have
a
certain
dot.
B
So
that's
really
exciting
and
I
think
the
most
exciting
thing
about
that
example
and
many
of
the
signing
with
ethereum
examples
is
that
no
one
had
to
ask
like
the
person
who
you
know
minted
the
nft
or
something
permission
to
provide
an
improved
user
experience
for
those
users.
They
could
just
implement
signing
with
ethereum
and
after
authenticating
read
the
data
and
bam
you
have
like
a
portal
for
that
community.
B
So
that's
pretty
permissionless
to
be
able
to
just
integrate
like
that.
Also,
basically,
with
the
combination
of
e
and
s,
data
you'd
have
a
public
profile.
You
can
take
with
you.
You
know
across
the
web,
if
you
sign
in
with
ethereum
load
your
information,
it's
kind
of
like
gravatar,
but
with
a
another
growth
trajectory
ahead
of
it.
So
we're
really
excited
about
this
combination
too.
B
So
just
some
terms,
we
went
over
what
a
relying
party
is,
but
just
as
a
refresher,
it's
someone
who's
trying
to
rely
on
the
session
data,
so
a
server
that
wants
to
make
sure
you
are
who
you
say
you
are
before
giving
you
advanced
access,
so
they
will
verify
the
sign
with
their
message
format
that
we
specified
and
create
a
session
bound
to
the
address.
Typically,
this
could
be
a
cookie
based
session,
so
it
works
a
lot
like
web
2..
B
There's
something
called
session
keys
that
we
can
talk
about
later,
as
well
as
another
way
to
do
that
and
interpreting
and
resolving
further
resources
associated
to
the
account
on
the
wallet
side.
It's
important
that
the
wallets
verify
the
message
they
verify
domain
binding,
which
is
really
important
for
security,
because
right
now
one
one
thing.
B
There
are
other
ways
to
you
know,
look
at
this
problem,
but
it
all
involves.
We
need
the
wallets
to
help
protect
their
users,
and
another
thing
that
wallets
can
do
is
create
very
user-friendly
interfaces
once
they
know
the
message
format
to
expect
right,
instead
of
just
signing
a
blob
of
text.
What
if
you
can
interpret
parts
of
the
text
and
display
a
really
like
semantic
ux,
the
user
knows
exactly
what
they're
doing
right
and
then
they're
able
to
they're
able
to
have
a
great
user
experience.
B
B
Basically,
as
you
navigate
the
internet
and
you
log
in
with
the
same
username
and
password
or
kind
of
load,
the
same
tracking
pixel
that
you
know
is
able
to
see
who
you
are
you're
running
into
identifier,
reuse,
by
using
the
same
identifier
from
site
to
site,
people
might
be
able
to
build
some
kind
of
profile
about
you
behind
your
back,
compromising
your
privacy
in
innovative
ways
right.
So
in
order
to
prevent
that,
ideally,
every
new
interaction
you
have
digitally
just
starts
with
a
new,
completely
uncorrelated
identifier.
B
B
This
is
something
that,
fortunately,
we
don't
have
too
big
of
an
issue
with,
but
the
current
demographic
of
users
that
want
to
use
dapps.
They
basically
want
to
show
that
they
have
nft,
ownerships
and
users
of
a
lot
of
the
web.
3
wallets
have
really
good
hygiene.
We
found
in
some
demographics
with
respect
to
having
like
a
different
account
for
a
public
persona
versus
for
trades
they'd,
rather
keep
private
versus
accounts
for
different
purposes.
B
We
need
the
wallets
help
once
again
to
improve
the
ability
to
create
new
identifiers
per
interaction.
I
think
I've
seen
some
pretty
interesting
work
from
the
brave
team
on
this,
where
they
they
had
to
modify
metamask.
I
believe
to
create
a
new
key
pair
for
connecting
to
adapt
right
and
that's
exactly
the
kind
of
direction
we
need
to
move
to.
Basically,
another
approach
towards
the
identifier,
reuse
mitigation
could
potentially
be
through
metamask,
snaps
and
other
similar
modules
that
allow
new
keys
to
be
generated
per
session.
B
I
think
you
can
access
entropy
there
so
really
interested
in
working
with
wallets
and
figuring
out.
What
more
can
be
done
here?
There's
also
things
in
the
realms
of
zkp's
and
circuits
that
we
can
use
if
you
can
demonstrate
a
certain
link
to
a
new
identifier
like
a
pool
of
identifiers
you're,
like
you
know,
one
of
these
owners
of
a
class
of
nfcs
or
something
right
and
you're
able
to
somehow
sign
with
that.
That's
really
interesting
as
well.
B
The
next
one
is
key
management,
as
I
mentioned
it's
one
of
the
biggest
challenges
in
the
industry
today,
and
I
think
that
we've
seen
great
progress
and
we'll
continue
to
see
that
I
think
I
mentioned
about
how,
when
we
move
to
when
we
support
multi-sigs
we're
able
to
take
advantage
of
a
lot
of
the
innovation
that
will
happen
in
the
space
wallet
and
server
security.
We
went
over
a
few
of
those
already
making
sure
that
the
relying
party
and
the
wallet
are
validating
message
formats.
B
Most
important
to
me
is
ensuring
domain
binding
at
the
wallet
level,
so
we're
really
protecting
users
from
in
the
middle
attacks
right.
So
we
really
want
to
advocate
for
that,
and
that's
why
you
know.
We
hope
that
wallets
will
adopt
the
standards
so
that
their
users
can
be
safer,
also
minimizing
wallet
and
server.
Interaction.
B
What's
really
interesting
is
that
there
are
some
ways
you
can
generate
the
message
entirely
from
the
wallet
and
you
don't
even
need
to
ask
the
server
for
any
kind
of
information,
the
fewer
interactions
you
have
between
a
backend
server
and
the
wallet
the
better
it
is
to
achieve
potential
privacy
for
the
user
right.
So
how
can
you
do
that?
If
we
have
fields
like
a
nonce
or
something
well,
what
you
can
do
is
maybe
agree
on
the
latest
block
hash
as
the
nods
right
to
prevent
replay
attacks
or
just
expect
the
current
system
time.
B
B
B
You
know
to
be
able
to
add
some
resources,
additional
that
the
server
could
access?
We
have
a
resources
section
that
you
know
is
up
for
interpretation,
we're
not
focused
on
authorization.
In
this
specification
we
just
wanted
to
allow
the
extensibility
into
there.
So
there's
a
field
called
resources
which
is
just
a
list
of
uris.
B
There's
some
interesting
challenges
with
wallet
connect
in
its
current
form,
because
right
now,
you're
unable
to
like
when
you
connect
to
wall
connect,
you
basically
are
staring
at
the
other
end
of
an
encrypted
tunnel
right
and
you
actually
don't
know
where
you
are
on
the
other
side
right.
So
how
can
we
add
the
functionality?
So
you
can
ask
about,
and
you
know
ascertain
who
you're
actually
talking
to
so
right
now
the
user
will
have
to
examine
you
know:
they'll
have
to
examine
the
domain
in
their
browsers.
B
B
This
is
especially
important
to
consider
if
you're,
using
eip1271,
which
is
the
smart
contract
wallet
specification,
because,
if
you're
relying
on
a
multi-sig
to
log
in
right,
the
multi-sig
group
changes.
You
should
probably
invalidate
all
the
sessions
depending
on
your
security
model.
But
that
sounds
like
a
good
direction
to
lean
towards
right.
So
it
really
depends
on
how
you
set
it
up
and
what
you
support
great.
So
we've
had
community
involvement,
a
lot
of
it
and
we're
really
proud
of
how
it
was
conducted,
basically
the
whole
development
of
the
standard.
B
We
had
reports
on
the
regular
to
the
community
in
a
public
open,
a
community
chat
every
week
or
other
week.
We
would
invite
anyone
who
wanted
to
hear
about
it
to
hear
the
updates
about
how
signing
with
the
theorem
was
going
decisions
made
in
the
spec.
We
had
a
long
discussion
about
eip
191
versus
eip
712,
which
you
have
the
benefit
of
hearing
about
here,
a
little
bit.
B
A
lot
of
great
points
were
made,
including
forwards
compatibility
with
new
extensions
to
the
openid
connect
framework,
and
we
can
talk
about
that
in
a
bit
and
it's
all
recorded.
It's
all.
On
the
internet,
we
have
notes
from
every
meeting.
So
if
you
want
to
see
the
of
all
the
evolution
of
the
spec
and
the
decisions
that
were
made
based
on
feedback
from
experts
in
the
call
we
had
people
from
wallet
companies,
we
had
end
users,
we
had
developers
writing
apps.
We
have
people
who
have
been
working
the
identity
space
for
like
20
years.
B
You
know
just
working
on
a
lot
of
the
saml
systems
and
early
days
of
oauth,
and
things
like
that.
So
we're
really
proud
of
how
diverse
the
community
was
and
the
level
of
questioning
and
discussion
that
took
place.
There
feel
free
to
look
at
any
of
the
recordings.
If
you
have
questions
about
it
and
the
top
things
that
we
talked
about,
I
just
kind
of
went
over,
but
security
mechanisms
pragmatism
trade-offs,
so
that
we
make
sure
that
it's
something
people
can
use
different
signing
formats
and
contract
wallet
support.
B
If
you
want
to
learn
more,
it's
all
at
login.xyz
the
recording
notes,
everything
there's
even
a
demo
there
you
can
use
to
see
how
it
works.
We
have
documentation
released
if
you
want
to
walk
through
how
you
implement
us,
client
and
server
side
support,
and
we
have
language
support
too.
Basically,
I
would
just
talk
about
the
language
support
a
little
bit,
so
you
can
look
at
the
documentation
docs.login.xyz.
It
should
be
pretty
apparent
on
the
website.
If
you
just
go
to
log
into
xyz,
we
have
support
for
typescript
javascript
rust.
B
There
was
an
external
contributor
for
like
a
community
contributor
for
like
python
support,
which
was
amazing
to
see-
and
I
think
they're
working
on
django
support
now
too.
So
it's
awesome
to
see
like
independent
contributions
shout
out
to
aphri
who
implements
the
sorry,
the
ruby
gem
for
ethereum
support
more
generally.
Basically,
I
think
he
just
added
smart
contract
support
to
that
so
by
using
that
as
a
dependency,
we're
able
to
support
signing
with
ethereum
and
ruby
with
smart
contract
wallets.
B
So
there's
a
bunch
of
activity
and
support
going
on
we're,
looking
and
running
towards
integrations
for
rails
and
django.
Wordpress
a
lot
of
these
platforms
where
users
have
been
asking
for
it
and
we've
had
supporters
across
all
different
kinds,
as
I
mentioned
earlier,
so
the
next
steps
are
to
basically
have
continued
support
across
the
ecosystem.
All
these
different
languages
projects
use
cases
petition
for
better
wallet
interfaces
so
that
users
can
have
a
great
experience
when
they're
signing
with
ethereum
and
launching
with
web
2
partners.
B
I
think
publicly
time
magazine
and
adobe
have
said
that
they're
really
interested
in
this
and
want
it
on
the
roadmap,
and
this
is,
I
think,
a
moment
where
users
can
take
more
control
over
their
digital
interactions,
the
same
way
that
they
own
their
digital
assets.
You
know
your
keys,
your
crypto
becomes
your
keys,
your
data
right
and
we're
really
excited
for
that
to
move
forward
and
there's
a
lot
of
supporting
pieces
of
the
ecosystem
that
made
this
possible.
B
A
Thank
you
so
much
for
this
presentation.
I
remember
this
rfp
going
out
later
during
summer
or
fall
last
year.
I'm
really
happy
to
see
this
into
production
and
the
group
is
actually
working
on
it
and
also
the
acronym
the
cv.
That's
that's
pretty
interesting,
having
community
calls
for
proposal
is
also
a
very
good
way
of
generating
momentum.
So
thank
you
for
that.
We
would
be
happy
to
provide
any
support.
A
If
you
may
look
from
caterers
to
you,
know
kind
of
raise
awareness
more
on
that
already
you
guys
are
doing
a
great
job
just
adding
to
it.
We
can
see
that
there
are
a
few
question
in
the
chat.
Let's
start
from
there
alita.
I
know
you
have
posted
a
bunch,
so
if
you
would
like
to
go
ahead
and
read
any
for
the
guest.
D
B
Absolutely,
I
think,
that's
a
really
creative
application
of
it.
That
would
work
perfectly
so
a
little
context,
sms
authentication,
meaning
you
get
like
a
text
message
and
then
you
know
it
has
a
unique
code
for
you
to
finish
your
login,
I'm
sure
everyone's
kind
of
encountered
this
before
in
their
lives
sometime
and
then
people
tweet
about
how
apple's
so
good
at
reading
the
code
and
putting
into
the
box
for
you.
But
aside
from
that,
it's
been
pretty
like
recommended
against.
B
I
think
the
federal
recommendation
in
the
us
is
like
new
security
systems.
Don't
use
it
because
some
jacking
a
whole
bunch
of
other
things.
There's
kind
of
a
counter
argument
about
accessibility
of
sms
and
a
lot
of
people
have
it,
but
you
know
I
think
it's
something
that
people
acknowledge.
We
should
deprecate
this
and
move
to
something
better,
something
better
could
be
signing
in
with
ethereum,
in
addition
to
your
normal
username
and
password
right.
What
if
you
could
use
signing
with
ethereum
as
a
multi-factor,
a
multiple
factor
in
your
authentication?
D
Yeah
I'll
ask
one
more
question
and
I'll
kind
of
add
a
bit
of
my
own
thing.
The
reason
I
have
a
problem
with
sms
authentication
is
because
when
you
change
your
phone
number,
it
eventually
gets
recycled
and
then
therefore
somebody
now
owns
all
of
your
accounts,
some
random
person,
which
is
what's
happening
to
me,
but
anyway,
a
question
from.
Does
the
on-chain
infrastructure
require
high-tech
clients?
I
know
you
mentioned
that
the
wallets,
and
this
actually
really
did
another
question.
B
B
In
fact,
I
think,
like
20
years
ago,
these
same
discussions
were
probably
had
with
all
the
browsers
and
the
web
servers
out
there
in
terms
of
oh
now,
all
the
browsers
have
to
like
update
to.
You
know
read
like
this
new
html
tag
or
something
right
and
kind
of
same
same
kind
of
challenge.
Here
I
think
what
we
learned
is
like
the
hardest
part
of
doing.
B
This
was
actually
the
human
coordination
and
doing
over,
like
80
interviews
with
companies
to
figure
out
what
they
cared
about
and
what
would
work
for
them
right
but
like
by
having
the
community
call
and
a
watering
hole
for
people
to
gather
around.
It's
actually
been
like
really
convenient
to
get
a
lot
of
those
conversations
going
on
in
the
first
place
and
just
kind
of
being
communicative
about
the
changes,
the
benefits
to
users.
You
know
going
on
excellent
programs
like
this.
To
talk
about
it
too,
is
extremely
helpful.
B
So,
basically
that's
one
part
of
it
in
terms
of
the
technical
upgrade
process.
Yes,
we
are
planning
to.
Basically
we
are
planning
to
basically
make
it
as
easy
as
importing
a
library
and
checking
a
message
format
and
not
having
to
maintain
that
part
of
the
code
making
sure
that
we're
defining
a
good
api
around
the
whole
sign-in
with
ethereum
process,
whether
you're
a
relying
party
or
client.
B
So
hopefully
there
will
be
its
own
momentum
for
that,
but
with
respect
to
the
message,
format
and
the
cryptographic
verification,
you
know
we're
hoping
to
just
do
a
really
good
job
of
the
libraries
there,
including
considering
formal
audits
and
bug
bounties
and
such
but
the
code.
Fortunately,
is
so
small
that
a
lot
of
the
security
engineers
that
we've
talked
to
at
people
who
want
to
adopt
are
actually
pretty
comfortable
with
it
already.
B
B
Identifier.
Reuse
is
the
top
concern
under
the
security
consideration.
Section
though,
and
that's
really,
I
think,
related
to
this
correlation
of
other
data.
I
think
that
we
should
move
towards
a
system
where
you
hopefully
get
a
new
identifier
for
every
interaction
and
just
populate
the
session,
with
the
data
that
are
relevant.
So
that's
definitely
the
direction.
I
think
we
need
to
move
and
we
have
to
be
very.
B
Yeah,
we
have
to
solve
things
one
block
at
a
time,
and
here
we
define
like
authentication
message
format.
That's
not
to
say
we
you
know,
aren't
focused
on
other
like
ways
to
address
the
identifier.
Reuse
thing
problem,
but
I
think
that
for
the
purposes
of
this
spec
we're
trying
to
keep
the
scope
constrained
to
just
that,
the
best
we
can
do
within
the
spec
itself
is
call
it
out
as
a
big
issue.
A
A
Maybe
we
can
go
ahead
and
read
the
question.
I'm
not
sure
if
this
has
already
been
answered.
So
if
you
would
like,
you
can
definitely
repost
that
question
for
the
guest
to
look
into
it
itself,
but
I'm
reading
the
question
that
is
there
from
jose
looking
into
the
top
the
question:
are
there
any
fees
involved
you
already
did
mention
about?
There
are
no
gas,
but
is
it
a
monthly
payment
or
each
time
user
validate
his
id.
A
E
So
my
question
is
essentially
so:
metamask
recently
released
a
developer
wallet,
it's
called
flask
and
they
introduced
a
feature
called
snap,
which
is
very
cool,
basically
have
sandbox
javascript
running.
So
what
do
you
see
that
might
be
currently
limiting,
depending
on
the
metamask
functionalities,
that
sign
in
with
ethereum
project
can
use
in
the
snap
versions?
Eventually.
B
Right
great
question:
I
think
this
is
really
a
great
discussion
because
it's
related
to
elita's
earlier
points
about
correlation
for
the
user
right.
So
one
of
the
really
cool
things
that
I
like
about
the
metamask
snaps
is
that
you
can
use
it.
You
can
derive
additional
like
entropy
from
the
api
they
expose,
I
believe
at
least
that's
a
rough
understanding
of
it
and
that
you
can
generate
a
new
like
ethereum
address
just
to
log
into
a
specific
service
right
and
maybe
for
that
specific
service.
B
You
only
want
to
show
that
it's
also
tied
to
you
know
your
twitter
account
and
that's
it
right
and
then
for
a
different
service.
It's
yet
another
identifier
that
you
generate
and
then
you're
able
to
tie
it
to
a
different
set
of
information
that
is
appropriate
right
so
and
there
are,
there
are
privacy,
improving
techniques
to
take
these
signed
claims
about
things
like
I
have
this
twitter
handle
and
digitally
signed
and
basically
selectively
disclose
smaller
pieces
of
it
without
showing
the
whole
thing.
A
I
see
there
is
another
interesting
question
it
was
posted
earlier.
Does
this
pave
the
way
for
users
to
be
able
to
sign
into
a
website
without
having
to
install
a
browser
extension
and
the
the
person
is
particularly
interested
in
how
this
could
be
a
ux
improvement
for
centralized
exchange
users
coming
over
to
the
d5
space.
B
Yeah,
so
I
so,
I
think
that's
a
great
two-part
question,
so
one
is
kind
of
like.
Is
this
going
to
work
without
a
user
installing
a
browser
extension
right,
and
I
think
the
answer
is
like
it
would
already
work
in
some
browsers
that
naturally
support
wallets,
for
example,
I
believe
brave
supports
wallets,
I
don't
know
the
status
of
their
eip
one-on-one
signing.
I
know.
Opera
supports
custodial
operations
as
well
within
the
wallets
within
the
browser.
Actually,
so
you
know
what's
interesting
is
that
some
browsers
would
already
support
it
without
an
extension.
B
There
are
other
ways
to
do
it
as
well.
I
haven't
researched
the
security
implications
of
them,
but
there
are
solutions
like
magic
link
and
taurus,
now
known
as
web
3
auth
that
allow
you
to
construct
basically
a
embedded,
iframe
wallet
or
similar
or,
and
you
don't
need
to
install
a
browser
extension
to
use
that.
Presumably,
if
you
signed
sign
in
with
ethereum
message,
it
would
work
the
same
way.
So,
yes,
there
are
ways
to
use
it
without
the
wallet
extension.
B
B
First,
maybe
using
even
your
ethereum
address
as
multi-factor
as
mentioned
earlier,
could
be
a
cool
idea,
but,
as
you
want
to
you
know,
maybe
associate
a
specific
ethereum
account
with
your
exchange
account.
You
know
you're
able
to
do
that.
You
have
to
be
cognizant
about
what
you're
telling
the
exchange,
though,
because
you
know
your
other
data
are
linked
there.
So
I
would
super
caution
that,
but
we
could
see
a
world
where
you
know
like.
Maybe
you
can
participate
in
airdrops
or
anything
from
the
exchange
wallet.
B
If
you,
you
know,
link
the
right
ethereum
address
to
that
account
right.
That
could
be
a
really
cool
way
for
people
who
use
centralized
exchanges
to
get
some
get
some
interaction
with
the
d5
markets
or
nfts,
or
anything
like
that.
So
I
think
there's
a
lot
that
can
happen
there
and
it'll.
It
could
also
lead
to
a
gradual
transition
from
exchange
assets
to
easy
export
to
your
own
accounts.
B
A
That's
pretty
interesting,
thank
you
for
the
answer
I
was
about
to
get
into
some
process
related
question,
but
there
is
another
very
interesting
question
coming
up
in
the
chat.
If
you
would
like
to
quickly
respond
to
that,
would
it
be
possible
or
any
other
further
integration
support
for
extending
the
sign
in
with
the
ethereum
to
physical
asset
that
have
some
communication
layer
or
like
wi-fi
bluetooth,.
B
B
You
know
that
these
are
some
of
the
considerations
you'd
have
to
make,
but
there's
no
reason
why
iot
devices
wouldn't
be
able
to
support
it,
for
example.
So
I
think
that,
like
I
think
it's
a
really.
I
think
we
even
saw
a
demo
of
it
over
like
machine
to
machine
like
server
to
server
sign
in
with
ethereum
right
just
uses
the
message
format
and
doesn't
show
the
user,
but
they
use
it
to
establish
the
session
so
really
excited
to
watch.
It
evolve.
A
A
B
We
talked
about
this
at
length
earlier,
and
you
know
it
has
to
do
with
identifier
reuse.
I
think
that
you
know
we
would
definitely
caution
against
tying
all
elements
of
an
identity
to
a
single
key,
but
I
think
that
per
use,
keys,
disposable
keys
is
the
way
right
and
I
think
you
run
into
huge
privacy
issues
if
you're
trying
to
just
have
a
forever
and
always
key
and
use
it
for
everything.
A
B
Yes,
so
the
issue
in
the
github
repository
made
was
referring
to
a
regex
implementation
which
is
not
used
in
terms
of
the
actual
library.
So
if
you
install
the
library
and
use
it,
we
literally
use
the
abnf
grammar,
that's
in
the
spec
and
interpret
it
using
an
abnf
grammar
interpreter
and
that's
the
typescript
library,
and
there
have
been
no
issues
with
that
because
we
found
the
abnf
library
to
be
correct.
B
B
A
That's
nice
one
other
question
about
the
proposal.
This
particular
proposal
lists
a
lot
of
proposals,
as
requires
like
they
are
added
in
required
section.
Most
of
them
are
already
in
the
final
status,
except
for
1328.
So
I'm
curious
to
understand
how
much
dependency
of
1328
is
there
on
the
proposal.
I
do
remember
that
you
mentioned
wallet
connect
a
couple
of
times
in
your
presentation.
A
B
A
Yeah
that
would
be
helpful
because
to
move
any
proposal
to
what
final
status
we
generally
recommend
the
proposals.
Those
are
in
the
category
must
be
in
the
final
status,
so
I
mean
if
if
there
would
have
been
any
hard
and
fine
requirement
of
it,
then
they
would
have
requested
you
to
probably
push
the
other
proposal
to
get
alongside
to
the
final
status.
B
A
B
Yeah,
so
if
you
were
like
you
know,
forging
a
tool
or
something
you
know,
I
think
the
general
shape
is
pretty
set
and
we
even
have
some
of
the
finer
details
of
handout.
Now
it's
all
about,
like
polishing
and
addressing
things
like
superfluous
required
eips
and
things
like
that.
But
I
think
the
the
heft
of
it
is
generally
agreed
upon
by
the
community
really
excited
to
take
care
of
the
last
few
items
and
then
race
it
towards
final
status.
A
A
B
A
Well,
thank
you
so
much,
and
on
this
note
I
would
like
to
thank
all
our
youtubers
for
watching
this
episode.
Please
check
out
the
description
section
for
related
links
and
obviously
we'll
be
trying
to
add
all
demo
links
whatever
is
available.
The
twitter
profile
for
the
guest
is
also
added
here,
so
you
can
follow
them
and
ask
the
questions
directly.
If
you
like
this
episode,
hit
like
button
share
it
with
people
sharing
is
important.
We
would
like
more
projects
to
know
about
this
proposal
and
hopefully
will
it
increase
the
adoption.
A
Should
you
have
any
question,
leave
a
comment.
Let
us
know
even
on
the
east
discord,
if
you
would
want
to
hear
more
about
this
proposal
or
any
upcoming
proposals
well
subscribe
to
ethereum
cathedrals
youtube.
If
you
haven't
done
it
already
see
you
all
in
the
next
episode
with
another
interesting
proposal
till
then
keep
watching
keep
sharing
your
love
with
the
indian
catholic.