►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Deep Dive: CNCF Serverless WG/CloudEvents - Clemens Vasters, Microsoft & Vlad Ionescu, Independent
This session will provide a more in-depth discussion of the Serverless working group, the CloudEvents specification and the new Workflow sub-group. It will include a more interactive discussion with the audience around some of the technical challenges we're facing and to solicit feedback as to the needs of the community.
https://sched.co/MPjB
A
A
A
So,
let's
get
into
the
demo,
okay,
first
of
all,
I
build
this
demo
for
Amazons.
They
do
video
conversion
in
the
cloud.
Instead
of
having
video
be
transcoded
and
a
movie
just
in
hours
or
days
is
being
done
in
minutes
cloud
very
nice.
They
also
have
another
product
which
is
a
straining
delivering
video
to
your
end,
users,
everybody's
building
their
own
streaming
service
right
now.
So
this
is
helping
a
lot
with
that
and
they
just
announced
the
frame
DNA,
which
is
AI
for
video.
A
If
you
have
multiple
versions
say
a
version
that
sensor
does
version
then
does
not
censor.
This
helps
a
lot
with.
Managing
this
owns
owns
was,
and
is
a
start,
and
as
a
start-up,
they,
the
biggest
focus,
is
delivering
a
lot
of
features
fast
to
get
feedback
from
their
customers
to
improve
and
to
validate
your
market
use.
Fortunately,
they've
had
great
success,
and
that
means
that
now
they
do
have
a
paying
customers.
A
They
have
to
focus
on
reliability,
so
they
need
to
do
the
whole
switch
from
yes,
while
building
fast,
we
were
breaking
stuff,
okay,
well,
building
fast,
but
we
are
focusing
on
reliable.
They
were
focusing
on
the
customer
experience
so
to
help
with
this.
What
we
thought
we
would
do
is
a
deployment
pipeline,
that's
something
that
was
missing.
We
kind
of
have
something
right
now,
which
is
working,
but
it
is
not
ideal
where
we
want
to
go.
Is
we
want
to
have
a
fully
observable
deployment
pipeline?
A
So
if
something
fails
at
any
stage
in
the
pipeline,
we
want
to
know
about
it.
We
don't
want
to
spend
hours
looking
through
log.
The
switching
contact
between
github
circle
see
our
other
tools
to
see
where
a
build
fellow,
where
a
deploy
is
down
also
working
with
video.
They
need
to
adhere
to
a
lot
of
compliance
standards.
Mpaa
is
an
example,
and
those
are
very
strict,
so
the
whole
deployment
pipeline
needs
to
be
very,
very
auditable
and
it
needs
to
have
steps
like
okay.
A
Somebody
needs
to
approve
this
deployment
going
to
a
client
environment
manually
also
from
a
development
perspective.
This
needs
to
be
fast
and
it
needs
to
be
scalable
building
developer
environments
at
the
start
of
every
day,
they're,
obviously
going
to
be
a
lot
of
deploys
and
at
night
just
a
couple
and
having
this
kill
for
this
would
be
absolutely
perfect,
as
we
don't
want
it
to
be
slow
in
any
way,
as
that
would
impact
velocity.
So
we
started
thinking
about
okay.
How
should
we
build
this?
Obviously,
the
first
step
is
getting
data
from
github.
A
All
our
social.
Our
source
code
is
hosted
in
github
and
github,
centralized
feature
which
is
called
records
and
they
send
you
a
web
hook,
a
big
JSON
containing
everything
that's
happening
in
your
repo
say
you
just
push
the
commit.
Do
you
have
this
be
as
full
torrent
as
possible
and
as
reliable
as
possible?
A
They
can
only
subscribe
to
some
events
that
they
care
about
I,
only
care
about
to
issue
comments,
I,
don't
care
about
commits
because
I'm,
a
bot
that
does
github
issue
automation,
stuff,
it's
pretty
much
the
same
thing
for
circle
CI,
when
a
build
is
done
where
a
test
has
failed.
I
want
to
know.
I
might
be
interested
in
different
events
in
different
types
of
events.
A
Sorry,
so
this
is
what
we
came
up
for
here.
The
proof
of
concept
and
the
demo
that
we'll
be
presenting
today
there
are
the
SNS
is
I
just
spoke
about
the
circle.
Cin
give
happiness,
is
they
all
send
their
events
to
a
lambda
which
of
course
them
in
a
dynamodb
table
this
dynamodb
stream?
If
you're
not
familiar
with
it,
think
of
it
as
tour
procedures
but
more
powerful
each
time
there
is
a
line
change
in
DynamoDB,
you
get
notified
and
you
can
run
lambda.
A
This
is
our
github
event.
Is
gonna,
be
first,
it's
gonna
go
to
lambda,
that's
gonna,
put
it
in
dynamodb
an
event.
Is
gonna
go
from
dynamodb
to
you,
the
other
lambda,
and
this
is
Nancy
okay.
This
is
not
ready
to
be
promoted.
This
is
the
promoter
lambda,
because
we
don't
have
an
image
yet
a
little
while
after
the
circle,
CI
event
is
going
to
get
triggered,
is
then
I'm
going
to
die.
Nobody
be
into
the
stream.
The
lambdas
no
I,
see
okay,
I
have
an
image.
A
A
A
A
B
A
A
Obviously
these
is
just.
This
is
just
a
demo.
So
there
are
just
two
data
sources:
Circle
CI
and
github.
You
can
add
as
many
as
you
want
what
what
a
promoter
lender
does
it
checks
if
they
are,
you
can
do
whatever
you
want
here.
So
you
can
check.
Hi
do
I,
have
approval
for
illegal?
Do
I?
Have
the
static
code
analysis
do
I?
Have
the
security
check
do
I?
Have
everything
I
need
in
here
there's
a
sponsor
version.
A
I
guess
now
we
know
what
we
want
to
build.
We
know
like
what
dataflow
will
be,
what
events
will
be
generated
and
how
we'll
be
acting
on
those
events.
So
now
we
now
we
got
to
do
even
design.
We
want
to
see
what
events
are
flowing
to
the
system
and
how
we
design
them.
So
what
do
we
need?
We
need
the
even
type
we
need
the
source
is
it
give
up.
Where
is
it
Circle
CI?
A
We
need
a
branch
and
we
need
a
git
commit
job
okay,
but
we
also
want
a
header
and
it's
a
trace
other,
which
is
terrible.
It
needs
to
be
serialize,
it
needs
to
be
serialize,
it
needs
to
be
taken
care
of
and
as
soon
as
we
got
to
this
place,
we
were
like
okay
building
our
own
JSON.
Our
own
data
structure
might
be
a
bit
too
much.
A
We
don't
want
to
do
that,
but
hey
we
know
about
clergyman's
cloud
events
has
the
exact
structure
and
it
enabled
us
to
very
easily
put
our
data
and
not
be
concerned
about
it.
Cloud
events
is
not
making
any
assumptions
about
your
actual
and
data
we
just
metadata.
That
goes
are
around
even
you
can
put
whatever
you
want
in
your
data,
so
you
can
go
as
well
as
you
can.
This
is
just
helping
with
routing.
So
do
you
want
to
know
if
there
was
build
success?
A
A
A
A
A
A
Okay,
so
we
can
see
that,
with
our
event
got
into
the
github
automation
part,
we
did
validate
the
github
signature,
we
did
validate
the
secret.
This
is
a
genuine
github
event.
We
generated
the
cloud
event.
We
can
even
see
it
we've
attached
it
as
contacts,
it's
basically
four
encoded,
but
it
is
there
and
then
we
want
into
the
handle
github
event
part.
We
read
the
previous
load
event.
We
were
generated.
A
We
created
our
dynamodb
table,
which
was
the
one
above,
and
you
can
see
some
little
here
circle
see
I
build
on
these
fools
is
not
ready.
We
wrote
that
dynamodb
and
the
promoter
lambda
got
him
and
shut
check
for
promotion,
and
we
have
our
f-type
promotion
failed.
Why
Circle
T
I
build
not
that
so
the
circle
via
build
is
still
happening,
looks
like
it
is
done
so
less
I'm,
not
gonna,
refresh
that
by
hand,
because
I
know
it's
acting
weird
open.
A
There
is
a
missing
span
somewhere,
I,
don't
see
it,
but
okay,
so
in
here
we
can
see
the
full
trace.
Why
spoke
early
about
the
level
of
the
of
absorbability
that
we
are
very,
very
much
interested
in?
So
this
is
the
span?
That's
missing,
okay,
so
we're
at
the
close.
If
we
got
what
is
this
apologies,
it
looks
like
some
events
did
not
get.
A
They
did
the
lambda
flushes
the
events
at
the
end
and
most
likely
it
would.
It
was
still
deploying
the
whole
chart.
So
that's
why
it
was
and
ready.
So,
let's
look
through
all
this
now
that
we
have
any
so
automation
promoter
check
for
promote
promotion,
promotion
failed.
This
is
where
we
were
before
it
waited
it
waited
the
circle.
Ca
even
came
in
the
promoter
function
ran
again
based
on
the
DynamoDB
stream.
It
checked
for
promotion.
A
It's
all
add,
that's
ok,
so
it
created
and
some
with
the
cloud
even
further
away,
and
then
we
got
into
the
held
install
automation,
there's
also
ready
vent.
It
did
some
preparing.
We
are
in
a
lambda
using
home.
We
are
authenticating
to
e
KS,
which
is
the
I.
Am
a
WSI
Authenticator,
so
we
need
to
do
quite
a
lot
of
stuff
for
that
we
install
the
Authenticator.
We
validate
that
installer.
We
have
access
to
it.
So
if
there's
any
issue
with
our
lambda,
we
do
want
to
know
about
it.
A
We're
preparing
for
help
will
anything
we'll
we
are
adding
our
Apple,
which
is
using
the
hub,
s3
plug-in,
which
is
amazing
and
I
highly
recommend
we
even
get
the
output.
So
if
there
is
an
issue
say
we
take
only
change
the
bucket
policy
and
this
lambda
is
no
longer
allowed
to
access
it.
We
will
be
able
to
see
that
here
and
then
we
did
install.
A
So
we
have
the
whole
output
and
if
we
go
to
the
coral
that
has
been
running
in
the
background,
you
can
see
hey
Keep,
Calm,
Plus
cloud
native
corn
Europe,
which
is
exactly
the
new
current
and
the
pods
that
are
running
any
case
are
all
around
2
minutes.
Also,
this
all
happened
between
the
demo.
The
deploy
was
fully
automated.
It
was
very
visible,
it
was
clear
and
it
was
very,
very
fast
and
scaling
super
fast.
This
also
allowed
us
and
encouraged
us.
A
This
is
a
la
hives
in
server
last
years
as
when
you're
doing
lambdas
and
several
eyes,
you
are
forced
to
invest
heavily
in
observability.
You
cannot
s
si
Jin.
You
cannot
do
that.
You
can
get
well
I'm,
not
SSH
back
to
you,
but
don't
do
that
and
being
forced
to
properly
instrument
the
applications
to
properly
get
visibility
into.
It
is
exactly
what
just
wants
to
add
to
its
all
products
and
what
we've
been
doing
for
the
last
month-
and
this
has
been
extremely
extremely
helpful
because
it's
been
a
safe
place
to
play
around
there.
A
Now,
let's
get
back
to
the
slides
slideshow
play
from
across
floor.
Okay,
so
up
sliding
hey
stuff,
didn't
work
so
about
the
external
events.
Experience
this
greatly
simplified
or
design
process.
We
didn't
have
to
do
any
encoding,
our
souls
and
decoding
we
have
as
decades
in
most
languages,
some
lenders
were
written
in
golang
somewhere
in
Python,
and
this
allows
us
exactly
that
flexibility.
It
also
comes
with
same
defaults.
A
In
that
event,
just
give
me
commit
just
give
me
issue
comments
and
again
flow
defense
does
not
restrict
what
you
put
in
data
and
all
it
just
adding
same
default,
same
values
to
help
you
around
that
as
you've
seen
I
haven't
thought
that
much
about
cloud
events
they're
here,
they're
boring
you
can
just
use
them
because
don't
design
your
own
JSON,
though
design
your
own
data
structures,
because
you're
gonna
get
issues,
and
now
we
actually
have
something.
That's
focusing
on
interoperability.
A
A
B
Okay,
you
will
be
my
clicky.
Everybody
go
back
to
that
side
great,
so
my
name
is
Clemens
I
work
for
Microsoft.
It's
not
a
startup
and
I
work
in
the
messaging
and
the
venting
team.
We
own
service,
boss,
event,
great
event,
hubs
relay
and
we
also
own
standardization
in
that
space,
which
means
were
engaged
in
C&C
of
cloud
events
will
also
engage
in
several
industrial
vertical
standards
and
were
and
I'm
the
technical
and
the
chair
of
the
Technical
Committee
for
mqp
and
Oasis.
B
So
a
few
architectural
considerations,
one
of
the
things
that
you
should
like
to
take
away
from
the
demo.
If
I
can
say
that
is,
standardization
helps
because
it
lets
you
build
an
application
one
application
based
on
heterogeneous
event,
sources
and
lets
you
handle
this
play
and
and
filter
events
in
a
common
way,
or
you
only
need
one
infrastructure.
If
those,
if
you
have
these
events
in
different
formats,
you
have
to
have
a
handler
and
filter
etc
for
each
of
the
event
types,
and
here
we
all
make
them
the
same.
We
have
a
effectively
simple
model.
B
We
have
the
the
minimal
set
of
things
to
treat
all
those
events
alike
and
that's
where
standardization
makes
sense
so
next
slide.
So
let's
go
in
and
think
briefly
and
this
come
it
guess.
It
goes
into
the
best
practices
section
what
events
are
and
and
how
they
are
different
for
messages,
because
that's
a
very
important
architectural
concern,
one
of
the
things
that
is
there's
a
slippery
slope
here
and
you
will
just
want
to
make
you
aware
of
that
events
are
not
messages
in
the
sense
of
telling
someone
something
to
do
and
they're
not
RPC.
B
It's
not
the
same
thing.
We're
designing
for
a
very
particular
subset
of
messages.
So
a
event
carries
a
fact.
It
carries
something
that
just
has
happened.
What
you
just
saw
in
that
demo
is
in
github.
You
did
something
you
committed
something
and
now
actions
happen
based
on
that
that
just
happened
they
propagate
through
a
system.
The
great
thing
about
those
facts
is
because
they
prescribed
the
describe
a
thing
that
has
already
occurred.
You
can
go
and
fan
them
out
to
everybody
and
you
can
go
and
write
them
down.
B
That's
different
from
the
intent
from
a
message
which
you
sent
to
someone
with
a
job
of
do
something
particular
so
we're
we're
just
reporting
things
out,
so
there's
some
principles
for
events
or
principles
for
pub/sub,
and
that's
also
what
we
have
in
mind
when
we
design
these
things.
We
have
a
notion
of
a
type.
B
We
have
the
notion
of
a
source.
Where
does
things
come
from
and
notions
of
a
subject?
What
is
this
event
about,
and
all
of
those
help
you
to
filter
out
messages
that
you're
interested
in
you
publish
events
into
space,
and
then
you
may
have
subscribers
who
are
interested,
in
particular
events,
we're
enabling
subscribing
to
those
and
some
of
the
principles,
our
publishers
don't
currently
know
who
subscribed,
you
might
publish
an
event,
but
there's
no
subscriber
for
it
and
that's
okay,
but
there
may
also
be
a
hundred
subscribers
to
it,
and
that's
also.
B
Okay
and
middleware
typically
helps
you
dealing
with
that
and
this
event
flow
is
generally
unidirectional,
which
means
you
sent
messages.
You
sent
those
events
out
and
there
is
no
response
path,
because
you
don't
expect
anybody
to
do
based
on
that
event,
but
they
enable
really
interesting
scenarios.
B
They
enable
extension
of
a
of
an
existing
application
with
new
functionality.
Without
you
telling
that
new
functionality
to
do
something
I'll
give
you
a
brief
example
that
are
always
used
for
a
venting,
which
is
something
that
works
on.
For
instance,
the
blobstore
that
we
have
in
in
Azure,
the
azure
blobstore
can
raise
an
event,
that's
called
blob
created
and
you
can
hook
on
to
the
blob
created
event
with
cloud
events
1.0.1
today
via
event
grid.
B
You
can
hook
a
handler
so
now
you
can
go
and
have
an
application
go
and
send
raw
pictures
from
let's
say
even
RAW
format,
pictures
from
a
camera
or
JPEGs
into
that
blob
account.
You
can
now
turn
that
into
a
photo
store,
because
you
can
hook
up
this
block
to
the
block
created
event.
The
application
goes
to
looks
at
the
image
and
first,
if
it's
a
raw
picture,
converts
it
with
default
settings
into
a
JPEG.
Now
you
have
a
JPEG.
B
Now
you
can
have
another
event
which
looks
at
the
subject
sees
that
there's
a
JPEG
in
there
and
now
goes
and
creates
five
thumbnails
for
different
sizes
and
stores
them
into
a
different
account.
You
can
have
another
hook.
That's
also
reacting
on
that
event,
which
goes
and
takes
that
image
and
runs
it
through
some
AI
classification
mechanism,
which
goes
and
creates
tags,
and
you
store
those
tags
into
a
index
database.
That
index
database
now
may
go,
go
and
raise
an
event
as
well.
B
You
go
and
hook
that
hook
hook
up
to
that,
and
then
you
can
go
with
that
reactor
that
event
and
import
that
into
your
news,
newsroom
image
database,
which
you
can
go
select
from
current
pictures
of
the
sports
game.
That's
currently
happening,
and
you
already
have
that
pre
tagged
and
you
already
have
the
source
to
the
original
picture
and
to
all
the
thumbnails,
and
you
have
done
nothing
other
than
reacting
to
events.
B
You
haven't
told
anybody
to
do
something,
but
everybody
is
just
reacting
building
functionality
on
top
of
it
as
an
extension,
it's
extension
programming,
it's
extension,
driven
programming
effectively,
you
drive.
Events
drives
the
functionality,
you
don't
tell
anybody
to
do
it,
but
applications
react
on
things
that
are
happening.
B
B
There
are
consequences
to
that.
There
are
architectural
consequences
to
that,
and
there's
also
infrastructural
consequences
to
this.
For
instance,
messages
typically
live
in
queues
or
often
live
in
queues,
because
you
want
one
party
to
pick
up
that
one
message,
because
you
want
that
job
to
be
what
done
once
an
event
typically
runs
on
the
pop
sub
system,
because
you
want
to
tell
something
about
that
happened
and
then
they
can
go
and
decide
whether
they
want
to
do
something.
B
And
very
often
you
will
find
that
messages
and
events
are
happening,
insisted
in
a
combined
fashion,
and
you
will
also
find
that
you
will
use
multiple
infrastructures
for
those.
If
you
have
streams
of
events
you
might
use
Kafka,
because
you
want
to
go
and
pull
those
events
to
a
place
to
go
and
do
and
analyze
them,
and
because
there
are
facts
and
things
that
are
happening.
There
won't
be
changing
anymore
and
the
context
won't
be
changing
anymore.
B
You
can
also
scroll
back
and
forwards
in
a
history,
then
you
have
event
routers
like
we
have
one
in
grid.
That
goes
and
take
an
event
and
push
it
out,
because
there's
no
context
required
between
those
events
and
sent
them
to
a
handler
like
lambda
or
are
a
national
function.
And
then
you
have
proper
message
queues
which
give
you
the
competing
consumer
model
that
you
need
for
assigning
work,
so
those
things
are
different
and
what
we
did
in
cloud
events.
B
We
picked
the
event
piece
and
how
can
we
go
and
deal
with
this
with
these
unidirectional
messages
and
how
we
can
can
we
make
those
look
the
same.
We
explicitly
scoped
out
the
messaging
aspects
and
we
might
in
a
different
work
streams
they'll
get
to
that
problem
of
where
they
want
you
and
unify
that.
But
cloud
event
is
not
that
next,
okay,
so
there's
stuff.
That
is
that
you
will
not
not
find
specifically
because
of
that
in
cloud
events
there's
no
to
attribute.
B
We
don't
tell
you
where
that
cloud,
where
that
message
should
be
sent
to,
because
we
assume
pops
up.
We
tell
you
when
that
message
comes
from
there's
also
no
reply
to
because
we're
directing
this
into
space,
and
we
don't
even
know
there,
anybody
would
reply.
We
have
not
because
we
have
no
expectations
of
replied.
This
is
not
a
job.
We're
expecting
any
replies
to
we're,
basically
just
telling
any
subscriber
who
likes
that
something
happened.
B
So
there's
no
reply,
which
means
that
cloud
events
is
also
not
there
to
go
and
model
your
RPC
exchanges,
at
least
not
in
the
standard
way.
The
envelope
is
suitable
for
it,
no
doubt,
but
that's
not
a
design
point
of
cloud
events,
because
and
and
and
when
I
say
envelope,
there's
a
slippery
slope
here,
because
there's
prior
art
that
we
also
didn't
and
I'm
not
going
to
mention
it.
B
But
we
we
didn't
want
to
go
on
the
slippery
slope
to
write
the
universal
Jason
everybody's
envelope
format,
but
wanted
to
build
something.
That's
specific
for
events
and
then
topic.
You
also
the
place
where
you
go
and
pull
and
put
that
event.
It's
also
not
in
the
message
or
in
the
event.
So
you
don't
have
a
notion
of
the
infrastructure
piece.
That's
accepting
that
event
and
the
reason
why
we
don't
have.
B
That
is
because
we
assume
that
events
will
be
forwarded,
that
events
will
travel
over
a
long
route
of
forwarders
that
they
might
go
come
from
a
might
come
over
HTTP.
My
then
land
in
a
queue
might
then
be
stored
in
a
database,
but
then
come
out
of
the
database
to
be
sent
to
someone
else,
and
you
know
the
whoever
sent
that
publish
that
event
initially
to
what
artifact
doesn't
matter,
because
we
assume
that
those
events,
those
captures
of
things
that
happened-
will
travel
and
will
probably
be
archived
for
a
very
long
time.
B
So
we
I
have
insisted
and-
and
a
lot
of
people
have
then
ended
up
agreeing,
luckily
to
say:
let's
get
1.0
done
first
and
then
let's
go
and
think
about
how
what
security
and
how
we
go
and
apply
security.
We
know
that
eventually
we
have
to
go
and
get
there,
but
I
think
that's
a
bigger
discussion
and
one
that
also
overlaps
with
things
that
we
have
in
other
areas
like
in
AMQP,
where
we
do.
B
You
know
full-on
messaging
what
we
need
to
have
mechanisms
that
are
similar,
so,
for
instance,
when
you
start
thinking
about
how
to
do
signatures
in
an
event
which
you
want
you
want
to
have.
Ultimately,
we
all
want
to
have
the
ability
to
go
and
sign
an
event
and
make
sure
that
the
event
we
get
over
here
it's
the
same,
that
was
published
over
there
and
you
should
be
able
to
sign
that.
The
question
is:
how
do
we
get
the
signing
key?
B
Who
signs
the
signing
key?
How
do
you
get
the
signing
key?
If
you
have
a
puff
subsystem,
you
publish
to
a
publishing
point
and
now
all
the
subscribers
you
can
go
and
subscribe
to
it.
How
does
the
subscriber
get
that
signing
key
and
when
that
signing
key
roles
which
it
will?
How
does
that
subscriber
get
that
new
signing
key?
B
How
do
you
know
the
signing
key
for
the
event
that
it
was
for
toasted
four
months
ago,
if
you
put
that
into
a
database,
and
you
see
an
event
that
was
posted
six
years
in
the
past
and
there
have
been
five
hundred
key
roles?
How
do
you
get
that
key
to
validate
the
signature
of
that
thing?
That
was
there
five
500
roles
ago
six
years
ago.
B
That's
not
trivial!
That
actually
requires
quite
a
bit
infrastructure,
quite
a
bit
of
protocol,
and
you
could
think
about
all
those
things,
and
you
can
think
about
approaches
to
this.
But
this
is
not
the
time
to
go
and
deal
with
it
and
and
I
believe
that
we
need
to
have
those
kinds
of
key
vaults
and
we
need
to
have
those
kinds
of
protocol
so
go
and
deal
with
those.
But
it's
probably
not
only
cloud
events
problem
to
go
and
solve.
B
Then
you
know
once
you
go
once
you
think
about
you
know
key
distribution,
it's
also
who
gets
access
to
those
keys,
and
why
and
what
is
the
identity
space
for
this?
So
that
gets
you
further
down
the
line
and
ultimately
you
get
to
the
point
of
identity
federation.
First,
then,
you
need
to
go
figure
out
how
to
have
authorization
for
or
whatever
the
key
vault
is.
B
Then
you
need
to
have
a
notion
of
how
that
key
vault
is
managing
those
things
and
then
have
a
way
to
go
and
correlate
that
key
vault
to
event
streams,
which
means
that
key
vault
really
needs
to
be
able
to
store
very
many
keys.
For
you
know,
periods
of
timing.
You
need
to
be
able
to
go
and
say:
I
have
an
event
from
five
years
ago
and
now
I
need
to
have
the
key
for
it.
So
that's
all
doable,
but
it's
not
something
that
we
can
go
just
solve
right
now.
B
So
that's
future
work
and
to
add
encryption
is
exactly
the
same
problem
because
you
also
need
to
have
need
to
have
key
material.
It's
just
harder,
because
encryption
keys
degrade
faster
in
this
world
because
we
have
sins
who
are
doing
data
grams
and
we
have
not
the
ability
to
go
in
and
negotiate
session
keys
because
there's
no
other
party,
we
basically
have
to
go
in
broadcast
and
we
have
to.
We
have
to
encrypt
data
grams
for
broadcast,
which
means
the
encryption
keys
degrade
very,
very
fast
through
use.
B
We
have
to
roll
them
more
often,
which
means
we
now
need
to
have
a
key
store
which
lets
you.
Let
us
also
again
same
same
problem,
get
at
historical
keys
fast
and
then
the
question:
how
does
that
work
again?
Something
that's
doable,
I
think
that's
a
job
that
we
all
need
to
go
and
figure
out
how
to
go
and
do.
B
But
it's
nothing
for
cloud
events
only
to
solve,
because
nqp
also
has
that
problem
and
that's
and
then
you
know,
without
even
looking
into
algorithms
and
algorithm
rolling
and
and
all
of
those
other
other
concerns
that
have
to
do
with
configuration
right
now.
I
sign
with
a
sha-3
and
sha-3
gets
goes
out
of
fashion
because
eventually
it
will
and
then
you
know
how
do
I
replace
that.
How
do
I
indicate
this
I
need
to
have
that
in
the
message.
B
B
B
Yes,
so
the
J
yet
so
the
question
is
the
JWT
to
Jayson
web
token
solve
some
of
those
concerns?
Yes,
it
does
it
so
there's
a
hole.
Josie
Jayson
object,
signature
and
encryption
set
of
specs
that
are
RFC's
now
with
where
my
colleague
Mike
Jones
also
contributed
to,
and
they
hail
from
effectively
equivalent
standards
from
the
xml
world.
And
yes,
so
there
are
some
components
that
are
solved
there,
but
it's
not
an
entire
suite.
It
doesn't
address
the
store
or
the
vault
or
any
of
those
things
so
yeah.
B
B
The
question
is
whether
project
Orleans
has
an
integration
with
this
I
have
haven't.
I
have
not
had
any
specific
discussion
about
this
with
those
guys,
but
we're
early
in
the
sense
in
that
we
haven't
locked
on
a
version
that
anybody
can
really
ship.
So
we
tried
to
get
there
very
quickly
and
then
we
certainly
at
Microsoft
has
the
intent
to
go
in
standardizing
cloud
events,
which
means
we
currently
have
a
native
format
for
event
grade.
B
Cloud
events
is
winning
well
cloud.
Events
is
certainly
something
that
we
want
to
use
and
there's
other
providers
who
are
also
want
to
use
it.
So
I,
don't
know
what
winning
means,
but
the
goal
is
that
we,
we
all
create
a
common
basis
to
go
and
do
events,
and
if
that
becomes
popular,
we're
all
happy.
You're
welcome.
B
So
the
question
is
since
signature
and
encryption,
all
those
things
are
not
there.
Do
you
think
it's
ready
to
take
on
critical
business
data
gtp
our
data,
it's
etc?
That's
the
discussion
we've
had,
and
so
my
answer
to
that
and
we've
had
that
in
the
context
of
the
discussion
about
the
claim
check
pattern
you
should,
since
you
should
always
assume
that
the
data
that
you
put
into
a
column
and
against
broadcast.